From ecrit-bounces@ietf.org Wed Mar 01 05:36:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEOhU-0005PV-Ln; Wed, 01 Mar 2006 05:36:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEObi-0004dt-AZ for ecrit@ietf.org; Wed, 01 Mar 2006 05:30:58 -0500 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEORb-0007Wf-GD for ecrit@ietf.org; Wed, 01 Mar 2006 05:20:32 -0500 Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k21AKJAU020234; Wed, 1 Mar 2006 11:20:19 +0100 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k21AKHO9022911; Wed, 1 Mar 2006 11:20:19 +0100 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 11:20:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt Date: Wed, 1 Mar 2006 11:19:19 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt thread-index: AcY5TKetQoR350pbSWi5nFNvOzctEgDytsxQ From: "Tschofenig, Hannes" To: "Tom-PT Taylor" , "Hannes Tschofenig" X-OriginalArrivalTime: 01 Mar 2006 10:20:16.0977 (UTC) FILETIME=[BC548410:01C63D19] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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: , Errors-To: ecrit-bounces@ietf.org hi tom,=20 please find my response below: > -----Urspr=FCngliche Nachricht----- > Von: Tom-PT Taylor [mailto:taylor@nortel.com]=20 > Gesendet: Freitag, 24. Februar 2006 15:12 > An: Hannes Tschofenig > Cc: ecrit@ietf.org > Betreff: Re: [Ecrit] Review of=20 > draft-taylor-ecrit-security-threats-02.txt >=20 > I'm pleased to get your response. I never got my copy of my E-mail to=20 > the list,so I was afraid it had disappeared into a black hole. >=20 > Just a couple of items to discuss, see below. Other stuff=20 > snipped away. >=20 > Hannes Tschofenig wrote: > > hi tom, > >=20 > > thanks for your response. > > please find some comments inline: > >=20 > > Tom-PT Taylor wrote: > >=20 > >> Here are my detailed responses. > >> > ... > >> > >> Comment: section 5.1, end of third para, what is meant by=20 > "installing=20 > >> filters"? > >> Response: What I meant by this was to say "intercept and discard=20 > >> mapping queries relating to the target at a router on the=20 > >> query-response path or at the mapping server". Because=20 > this is rather=20 > >> longer than the original, I'll rework the sentence=20 > structure to handle=20 > >> it. > >=20 > >=20 > > the problem is: how do you setup these filters to only drop=20 > queries by > > adversaries. this sounds like a difficult problem to me. > > furthermore, we are supposed to be indicating requirements=20 > rather than > > specific solutions. > >=20 > [PTT] No, I meant that the attacker installs the filters.=20 > Presumably the=20 > attacker has the information to construct them. how can the attacker install packet filters to discard mapping queries?=20 > >> > ... > >> > >> Comment: section 6, requirements in response to man-in-the-middle=20 > >> threat. Proposed alternative wording. > >> Response: Your wording introduces the issue I mentioned in=20 > my previous=20 > >> E-mail: do we require implementation or only make it possible to=20 > >> implement? > >=20 > >=20 > > you mean: implementation vs. usage > >=20 > > my impression is that we have to be explicit as whether we=20 > talk about > > usage or implementation when we use RFC 2119 language. we=20 > ask roger to > > walk through the requirements draft todo the same. hence, i think we > > should also apply it to this draft. > >=20 > > you are right that a MUST use in this particular case is really > > difficult to accomplish in all cases. > >=20 > > what about MUST implement and SHOULD use? > >=20 > [PTT] We've heard objections that MUST implement is unrealistic for a=20 > couple of reasons -- client resources and effect on call setup times.=20 i don't buy the story that a MUST implement for TLS is a problem. almost = every device today has TLS implemented already.=20 the aspect of call setup time only effects the "SHOULD use" part. here, = i again think that it is not a problem. TLS performance tests have shown = that it is not really a problem. what could cause problems is = certificate validation, path validation, CRL checking, etc.. this is, = however, a separate issue that we tried to soften with the "SHOULD" = regarding usage. > Anyway, a "MUST implement" provision would be part of the protocol=20 > specification rather than the requirements. What we would=20 > distinguish at=20 > the requirements level is "the protocol must provide" vs.=20 > "the protocol=20 > must not prevent". I am suggesting we use the latter. we use the RFC 2119 language in the security threats document as a = guideline to the protocol development. we do the same in the = requirements drafts. maybe we should add a sentence explaining this fact = to the terminology section in both the requirements and the security = threats draft to make it clear.=20 > >> > ... > >> > >> Comment: section 6, fraudulent calls, remark that reverse=20 > lookup is an=20 > >> unnecessary requirement. > >> Response: You're half right -- it is mostly an=20 > optimization. But then=20 > >> you're assuming that the VSP/ASP proxy is capable of reading the=20 > >> location from the INVITE so it can redo the lookup. Is this=20 > >> sufficiently problematic that we need the reverse lookup anyway? > >=20 > > we are entering solution specific teritory here. maybe we=20 > should talk > > about this at all in the draft. > >=20 > > here is my impression about this stuff in relationship to=20 > the ongoing > > solution specific work: > > we do not have the infrastructure to perform reverse=20 > lookups. we only > > worried about "Location -> URI" mapping. We have never=20 > looked at the URI > > -> Location mapping. > >=20 > > we should keep an eye on this issue. > >=20 > [PTT] The requirement doesn't go that far. What is needed is=20 > to be able=20 > to look up a URI and get back an assurance that the URI=20 > points to a PSAP=20 > -- a "yes" or "no". I'll make sure the wording is clear on this point. ok. sounds good to me. ciao hannes > > ciao > > hannes > >=20 > ... >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 01 06:36:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEPcT-0001MH-2e; Wed, 01 Mar 2006 06:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEPcR-0001M9-Q1 for ecrit@ietf.org; Wed, 01 Mar 2006 06:35:47 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEPcQ-0001ov-FJ for ecrit@ietf.org; Wed, 01 Mar 2006 06:35:47 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k21BZW1n010907; Wed, 1 Mar 2006 05:35:32 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Wed, 1 Mar 2006 11:35:31 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C2907E5@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] draft-ietf-ecrit-urn Date: Wed, 1 Mar 2006 11:35:30 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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: , Errors-To: ecrit-bounces@ietf.org Certainly in the 3GPP scheme of things, while the UA is required to try and identify emergency calls, it is regarded as fallible, and therefore the first proxy met (P-CSCF) will also perform an emergency call identification procedure. Therefore from a 3GPP perspective a proxy needs to be able to insert this marking. This first proxy is not the entity that performs the routeing analysis to determine which PSAP is to be used - that is performed by a later proxy in the path (E-CSCF), and therefore the Request-URI sent from this proxy will not be the PSAP URI, but will be the emergency URN. After the analysis is done the call is forwarded either to the PSAP (IP connected) or via another proxy (BGCF) and a gateway UA (MGCF) to the PSAP (PSTN connected). I assume the Request-URI in both these cases is no longer the emergency URN but represents directly the PSAP. This process is described more fully in http://www.3gpp.org/ftp/Specs/html-info/23167.htm Both before the proxy (E-CSCF) and after it, there is a need to mark the call in order to give it priority as the intermediate SIP entities are not necessarily dedicated entirely to emergency calls. I agree we should keep this simple. It also occurs to me that any recognition of the marking should also be possible reasonably early in the proxy processing (section 16.1 onwards of RFC 3261). regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 28 February 2006 20:32 > To: Drage, Keith (Keith) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-urn > > > I'm hoping that the use of the service URN in the SIP To > header field is > sufficient marking. In the sipping-sos case, I had split this > into two > since there was the perception that overloading the user field of the > URI with lots of different services would be a bad idea. This isn't > really a problem here. > > See http://www.cs.columbia.edu/~hgs/papers/2006/ecrit-arch.ppt for an > attempt to go through the various cases of who determines > that a call is > an emergency call. > > The one issue that arises is if the UA doesn't recognize > emergency calls > and just routes the SIP or tel URI to the proxy. The proxy > can't replace > the To header field, so there's no place to put a service > indication. I > don't know if that is important since the same entity will > also have to > do the mapping and thus insert a PSAP URI in the request URI > field. The > request will then visit that PSAP URI on the next hop. Unless a PSAP > were to use the same URI for both the general business > address and the > emergency contact address, there is no confusion and no additional > routing in the "public" SIP server space. (Commingling emergency and > non-emergency calls on the same SIP URI seems both ill-advised and > unnecessary.) > > Do you think we need the additional marker? (My general > inclination is > to keep things as simple as possible, i.e., to avoid adding > SIP header > fields if we can help it.) > > It would be easy to keep the same media feature tag as in sipping-sos: > > Accept-Contact: *;sip.service="urn:service:sos.marine" > > Opinions? > > Henning > > > Drage, Keith (Keith) wrote: > > I understood that the predecessor of this document > > > > draft-ietf-sipping-sos-02: Emergency Services URI for the > Session Initiation Protocol > > > > implicitly carried the implementation of the following > requirement from draft-ietf-ecrit-requirements-05, i.e. the > presence of the emergency URI was also the emergency marking. > > > > Id3. Emergency Marking: Any device in the signaling path that > > recognizes by some means that the signaling is > associated with an > > emergency call MUST add a specific emergency indication, if it > > doesn't already exist, to the signaling before forwarding it. > > This marking mechanism must be different than QoS marking. > > > > Motivation: Marking ensures proper handling as an > emergency call > > by downstream elements that may not recognize, for example, a > > local variant of a logical emergency address. > > > > So my question is as to whether the presence of the service > type "sos" defined in the new draft is sufficient indication > of this marking, or whether ecrit expects some other SIP > indication to give this emergency marking. > > > > regards > > > > Keith > > > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > > > > _______________________________________________ > > 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 Wed Mar 01 09:36:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESQu-0002Op-CB; Wed, 01 Mar 2006 09:36:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESQt-0002Mf-2Z for ecrit@ietf.org; Wed, 01 Mar 2006 09:36:03 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESQp-0008JF-NT for ecrit@ietf.org; Wed, 01 Mar 2006 09:36:03 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k21EZsDZ027998 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 1 Mar 2006 09:35:55 -0500 (EST) In-Reply-To: <475FF955A05DD411980D00508B6D5FB00C2907E5@en0033exch001u.uk.lucent.com> References: <475FF955A05DD411980D00508B6D5FB00C2907E5@en0033exch001u.uk.lucent.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26AEFF0A-E946-4B9A-85CC-12B15F6872A9@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] draft-ietf-ecrit-urn Date: Wed, 1 Mar 2006 09:35:51 -0500 To: "Drage, Keith (Keith)" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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: , Errors-To: ecrit-bounces@ietf.org If a priority marking is desired, maybe Resource-Priority is the right mechanism (with a new namespace). Would that suffice? On Mar 1, 2006, at 6:35 AM, Drage, Keith (Keith) wrote: > Certainly in the 3GPP scheme of things, while the UA is required to > try and identify emergency calls, it is regarded as fallible, and > therefore the first proxy met (P-CSCF) will also perform an > emergency call identification procedure. Therefore from a 3GPP > perspective a proxy needs to be able to insert this I don't see how this can work if the UA uses 'urn:service:sos' as the 'To' header field, as it should. Such proxy identification would only be needed if the UA doesn't know the dial string and uses either a tel or SIP URI. > marking. This first proxy is not the entity that performs the > routeing analysis to determine which PSAP is to be used - that is > performed by a later proxy in the path (E-CSCF), and therefore the > Request-URI sent from this proxy will not be the PSAP URI, but will > be the emergency URN. > > After the analysis is done the call is forwarded either to the PSAP > (IP connected) or via another proxy (BGCF) and a gateway UA (MGCF) > to the PSAP (PSTN connected). I assume the Request-URI in both > these cases is no longer the emergency URN but represents directly > the PSAP. > > This process is described more fully in http://www.3gpp.org/ftp/ > Specs/html-info/23167.htm > > Both before the proxy (E-CSCF) and after it, there is a need to > mark the call in order to give it priority as the intermediate SIP > entities are not necessarily dedicated entirely to emergency calls. > I agree we should keep this simple. It also occurs to me that any > recognition of the marking should also be possible reasonably early > in the proxy processing (section 16.1 onwards of RFC 3261). > > regards > > Keith > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: 28 February 2006 20:32 >> To: Drage, Keith (Keith) >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-urn >> >> >> I'm hoping that the use of the service URN in the SIP To >> header field is >> sufficient marking. In the sipping-sos case, I had split this >> into two >> since there was the perception that overloading the user field of the >> URI with lots of different services would be a bad idea. This isn't >> really a problem here. >> >> See http://www.cs.columbia.edu/~hgs/papers/2006/ecrit-arch.ppt for an >> attempt to go through the various cases of who determines >> that a call is >> an emergency call. >> >> The one issue that arises is if the UA doesn't recognize >> emergency calls >> and just routes the SIP or tel URI to the proxy. The proxy >> can't replace >> the To header field, so there's no place to put a service >> indication. I >> don't know if that is important since the same entity will >> also have to >> do the mapping and thus insert a PSAP URI in the request URI >> field. The >> request will then visit that PSAP URI on the next hop. Unless a PSAP >> were to use the same URI for both the general business >> address and the >> emergency contact address, there is no confusion and no additional >> routing in the "public" SIP server space. (Commingling emergency and >> non-emergency calls on the same SIP URI seems both ill-advised and >> unnecessary.) >> >> Do you think we need the additional marker? (My general >> inclination is >> to keep things as simple as possible, i.e., to avoid adding >> SIP header >> fields if we can help it.) >> >> It would be easy to keep the same media feature tag as in sipping- >> sos: >> >> Accept-Contact: *;sip.service="urn:service:sos.marine" >> >> Opinions? >> >> Henning >> >> >> Drage, Keith (Keith) wrote: >>> I understood that the predecessor of this document >>> >>> draft-ietf-sipping-sos-02: Emergency Services URI for the >> Session Initiation Protocol >>> >>> implicitly carried the implementation of the following >> requirement from draft-ietf-ecrit-requirements-05, i.e. the >> presence of the emergency URI was also the emergency marking. >>> >>> Id3. Emergency Marking: Any device in the signaling path that >>> recognizes by some means that the signaling is >> associated with an >>> emergency call MUST add a specific emergency indication, if it >>> doesn't already exist, to the signaling before forwarding it. >>> This marking mechanism must be different than QoS marking. >>> >>> Motivation: Marking ensures proper handling as an >> emergency call >>> by downstream elements that may not recognize, for example, a >>> local variant of a logical emergency address. >>> >>> So my question is as to whether the presence of the service >> type "sos" defined in the new draft is sufficient indication >> of this marking, or whether ecrit expects some other SIP >> indication to give this emergency marking. >>> >>> regards >>> >>> Keith >>> >>> Keith Drage >>> Lucent Technologies >>> drage@lucent.com >>> tel: +44 1793 776249 >>> >>> _______________________________________________ >>> 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 Wed Mar 01 10:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESvQ-0007z5-Ez; Wed, 01 Mar 2006 10:07:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FESvP-0007z0-CB for ecrit@ietf.org; Wed, 01 Mar 2006 10:07:35 -0500 Received: from ns2.sccx.com ([209.108.197.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FESvK-0000w7-Qy for ecrit@ietf.org; Wed, 01 Mar 2006 10:07:35 -0500 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] draft-ietf-ecrit-urn X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 1 Mar 2006 09:07:16 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A016B00CE@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] draft-ietf-ecrit-urn Thread-Index: AcY9JFIT2fL2tJ3RQYSLMyhz9Vsc/QADeEpA From: "McCalmont, Patti" To: "Drage, Keith \(Keith\)" , "Henning Schulzrinne" X-OriginalArrivalTime: 01 Mar 2006 15:07:18.0070 (UTC) FILETIME=[D4E6C560:01C63D41] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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: , Errors-To: ecrit-bounces@ietf.org Keith, I'm in agreement for the local network to add markings that identify the emergency call as early as possible. This enables, as you said, prioritizing the call by other proxies in the path. It also could be used as a means to detect the emergency call in a visited network and process the call locally. Patti McCalmont -----Original Message----- From: Drage, Keith (Keith) [mailto:drage@lucent.com]=20 Sent: Wednesday, March 01, 2006 5:36 AM To: 'Henning Schulzrinne' Cc: ecrit@ietf.org Subject: RE: [Ecrit] draft-ietf-ecrit-urn Certainly in the 3GPP scheme of things, while the UA is required to try and identify emergency calls, it is regarded as fallible, and therefore the first proxy met (P-CSCF) will also perform an emergency call identification procedure. Therefore from a 3GPP perspective a proxy needs to be able to insert this marking. This first proxy is not the entity that performs the routeing analysis to determine which PSAP is to be used - that is performed by a later proxy in the path (E-CSCF), and therefore the Request-URI sent from this proxy will not be the PSAP URI, but will be the emergency URN. After the analysis is done the call is forwarded either to the PSAP (IP connected) or via another proxy (BGCF) and a gateway UA (MGCF) to the PSAP (PSTN connected). I assume the Request-URI in both these cases is no longer the emergency URN but represents directly the PSAP. This process is described more fully in http://www.3gpp.org/ftp/Specs/html-info/23167.htm Both before the proxy (E-CSCF) and after it, there is a need to mark the call in order to give it priority as the intermediate SIP entities are not necessarily dedicated entirely to emergency calls. I agree we should keep this simple. It also occurs to me that any recognition of the marking should also be possible reasonably early in the proxy processing (section 16.1 onwards of RFC 3261). regards Keith > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 28 February 2006 20:32 > To: Drage, Keith (Keith) > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-urn >=20 >=20 > I'm hoping that the use of the service URN in the SIP To=20 > header field is=20 > sufficient marking. In the sipping-sos case, I had split this=20 > into two=20 > since there was the perception that overloading the user field of the=20 > URI with lots of different services would be a bad idea. This isn't=20 > really a problem here. >=20 > See http://www.cs.columbia.edu/~hgs/papers/2006/ecrit-arch.ppt for an=20 > attempt to go through the various cases of who determines=20 > that a call is=20 > an emergency call. >=20 > The one issue that arises is if the UA doesn't recognize=20 > emergency calls=20 > and just routes the SIP or tel URI to the proxy. The proxy=20 > can't replace=20 > the To header field, so there's no place to put a service=20 > indication. I=20 > don't know if that is important since the same entity will=20 > also have to=20 > do the mapping and thus insert a PSAP URI in the request URI=20 > field. The=20 > request will then visit that PSAP URI on the next hop. Unless a PSAP=20 > were to use the same URI for both the general business=20 > address and the=20 > emergency contact address, there is no confusion and no additional=20 > routing in the "public" SIP server space. (Commingling emergency and=20 > non-emergency calls on the same SIP URI seems both ill-advised and=20 > unnecessary.) >=20 > Do you think we need the additional marker? (My general=20 > inclination is=20 > to keep things as simple as possible, i.e., to avoid adding=20 > SIP header=20 > fields if we can help it.) >=20 > It would be easy to keep the same media feature tag as in sipping-sos: >=20 > Accept-Contact: *;sip.service=3D"urn:service:sos.marine" >=20 > Opinions? >=20 > Henning >=20 >=20 > Drage, Keith (Keith) wrote: > > I understood that the predecessor of this document=20 > >=20 > > draft-ietf-sipping-sos-02: Emergency Services URI for the=20 > Session Initiation Protocol > > =20 > > implicitly carried the implementation of the following=20 > requirement from draft-ietf-ecrit-requirements-05, i.e. the=20 > presence of the emergency URI was also the emergency marking. > >=20 > > Id3. Emergency Marking: Any device in the signaling path that > > recognizes by some means that the signaling is=20 > associated with an > > emergency call MUST add a specific emergency indication, if it > > doesn't already exist, to the signaling before forwarding it. > > This marking mechanism must be different than QoS marking. > >=20 > > Motivation: Marking ensures proper handling as an=20 > emergency call > > by downstream elements that may not recognize, for example, a > > local variant of a logical emergency address. > >=20 > > So my question is as to whether the presence of the service=20 > type "sos" defined in the new draft is sufficient indication=20 > of this marking, or whether ecrit expects some other SIP=20 > indication to give this emergency marking. > >=20 > > regards > >=20 > > Keith > >=20 > > Keith Drage > > Lucent Technologies > > drage@lucent.com > > tel: +44 1793 776249 > >=20 > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ 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 Wed Mar 01 11:40:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUMq-0003CD-Nu; Wed, 01 Mar 2006 11:40:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUMp-00039J-6F for ecrit@ietf.org; Wed, 01 Mar 2006 11:39:59 -0500 Received: from zcars04f.nortelnetworks.com ([47.129.242.57] helo=zcars04f.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEUMn-0005cb-U9 for ecrit@ietf.org; Wed, 01 Mar 2006 11:39:59 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k21Gdt012514 for ; Wed, 1 Mar 2006 11:39:55 -0500 (EST) Received: from [127.0.0.1] ([47.130.17.217] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 11:39:48 -0500 Message-ID: <4405CE50.4060103@nortel.com> Date: Wed, 01 Mar 2006 11:39:44 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2006 16:39:48.0732 (UTC) FILETIME=[C15A93C0:01C63D4E] X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ecrit] Definition of "emergency identifier" 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: , Errors-To: ecrit-bounces@ietf.org draft-ietf-ecrit-requirements-05 has the following definition for "emergency identifier": Emergency identifier: The numerical and/or text identifier which is supplied by a user or a user device, which identifies the call as an emergency call and is translated into an emergency address, useful for call routing and completion of the emergency call. The problem I see here is the phrase "is translated into". That would be true for a URN in the Request-URI, but doesn't work for one in the To: header field. My first suggestion is to terminate the definition after "... which identifies the call as an emergency call." The alternative is to go on to say "... and triggers emergency call routing procedures possibly including mapping of the caller's location to an emergency address.". Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 01 11:59:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUff-0002KF-KY; Wed, 01 Mar 2006 11:59:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEUfe-0002K9-Rm for ecrit@ietf.org; Wed, 01 Mar 2006 11:59:26 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEUfd-0006KI-IC for ecrit@ietf.org; Wed, 01 Mar 2006 11:59:26 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FEUfV-0004zO-HB; Wed, 01 Mar 2006 10:59:17 -0600 From: "Brian Rosen" To: "'Tom-PT Taylor'" , Subject: RE: [Ecrit] Definition of "emergency identifier" Date: Wed, 1 Mar 2006 11:59:15 -0500 Message-ID: <048401c63d51$7b2eae60$3d01a8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4405CE50.4060103@nortel.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcY9Tsiqr6DOg5iqQxqlfiweGnzPYwAAMgvw X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.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-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org This is part of the problem, but not the whole problem. I agree we need to have some kind of marking that identifies an emergency call. I think this marking has to be applied at any point where an entity recognizes that it is an emergency call. The point many folks have missed is that the marking has to stay on the call all the way to the UAS. We also need a marking that tells us that the call has been location routed. At one point, the way this worked was a call was marked urn:service:sos until it was location routed, but that marking is lost after it was. I think we need to know, after it's location routed, that it's (still) an emergency call. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortel.com] Sent: Wednesday, March 01, 2006 11:40 AM To: ecrit@ietf.org Subject: [Ecrit] Definition of "emergency identifier" draft-ietf-ecrit-requirements-05 has the following definition for "emergency identifier": Emergency identifier: The numerical and/or text identifier which is supplied by a user or a user device, which identifies the call as an emergency call and is translated into an emergency address, useful for call routing and completion of the emergency call. The problem I see here is the phrase "is translated into". That would be true for a URN in the Request-URI, but doesn't work for one in the To: header field. My first suggestion is to terminate the definition after "... which identifies the call as an emergency call." The alternative is to go on to say "... and triggers emergency call routing procedures possibly including mapping of the caller's location to an emergency address.". Tom Taylor _______________________________________________ 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 Wed Mar 01 13:09:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVlk-0007h1-Pb; Wed, 01 Mar 2006 13:09:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEVlj-0007eq-RU for ecrit@ietf.org; Wed, 01 Mar 2006 13:09:47 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEVli-0000e0-Iz for ecrit@ietf.org; Wed, 01 Mar 2006 13:09:47 -0500 Received: from lion.cs.columbia.edu (IDENT:4vJFngoviWrD8ZpWGXPQoLmZPX/P3GwG@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k21I9Weg009966 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 1 Mar 2006 13:09:43 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k21I9WjN020547 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 1 Mar 2006 13:09:32 -0500 Message-ID: <4405E357.2@cs.columbia.edu> Date: Wed, 01 Mar 2006 13:09:27 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Definition of "emergency identifier" References: <048401c63d51$7b2eae60$3d01a8c0@cis.neustar.com> In-Reply-To: <048401c63d51$7b2eae60$3d01a8c0@cis.neustar.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, __FRAUD_419_TINHORN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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: , Errors-To: ecrit-bounces@ietf.org In an earlier message in this thread, I had made two proposals: (1) Accept-Contact: *;sip.service="urn:service:sos.marine" [This was in sipping-sos.] (2) Resource-Priority (to indicate the need for priority) I'm happy to put (1) back into the service URN draft if this is considered an acceptable solution to the marking problem. I think it fits the caller preferences processing model pretty well. Brian Rosen wrote: > This is part of the problem, but not the whole problem. > > I agree we need to have some kind of marking that identifies an emergency > call. I think this marking has to be applied at any point where an entity > recognizes that it is an emergency call. The point many folks have missed > is that the marking has to stay on the call all the way to the UAS. > > We also need a marking that tells us that the call has been location routed. > > > At one point, the way this worked was a call was marked urn:service:sos > until it was location routed, but that marking is lost after it was. I > think we need to know, after it's location routed, that it's (still) an > emergency call. > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com] > Sent: Wednesday, March 01, 2006 11:40 AM > To: ecrit@ietf.org > Subject: [Ecrit] Definition of "emergency identifier" > > draft-ietf-ecrit-requirements-05 has the following definition for > "emergency identifier": > > Emergency identifier: The numerical and/or text identifier which is > supplied by a user or a user device, which identifies the call as > an emergency call and is translated into an emergency address, > useful for call routing and completion of the emergency call. > > The problem I see here is the phrase "is translated into". That would be > true for a URN in the Request-URI, but doesn't work for one in the To: > header field. My first suggestion is to terminate the definition after > "... which identifies the call as an emergency call." The alternative is > to go on to say "... and triggers emergency call routing procedures > possibly including mapping of the caller's location to an emergency > address.". > > Tom Taylor > > > > _______________________________________________ > 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 Wed Mar 01 13:28:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEW3p-0000jr-DQ; Wed, 01 Mar 2006 13:28:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEW3o-0000dg-6q for ecrit@ietf.org; Wed, 01 Mar 2006 13:28:28 -0500 Received: from zcars04e.nortelnetworks.com ([47.129.242.56] helo=zcars04e.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEW3n-0001Sa-TA for ecrit@ietf.org; Wed, 01 Mar 2006 13:28:28 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k21IOGE08965; Wed, 1 Mar 2006 13:24:16 -0500 (EST) Received: from [127.0.0.1] ([47.130.17.217] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 13:28:24 -0500 Message-ID: <4405E7C3.1050800@nortel.com> Date: Wed, 01 Mar 2006 13:28:19 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Definition of "emergency identifier" References: <048401c63d51$7b2eae60$3d01a8c0@cis.neustar.com> In-Reply-To: <048401c63d51$7b2eae60$3d01a8c0@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2006 18:28:24.0940 (UTC) FILETIME=[ED5102C0:01C63D5D] X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: ecrit-bounces@ietf.org I absolutely agree with the first requirement -- I raised that issue myself. I also raised the point that the marker may have to be present on signalling messages subsequent to the INVITE. That said, do people agree with my proposal to truncate the definition of emergency marking after the words: "... which identifies the call as an emergency call." Brian Rosen wrote: > This is part of the problem, but not the whole problem. > > I agree we need to have some kind of marking that identifies an emergency > call. I think this marking has to be applied at any point where an entity > recognizes that it is an emergency call. The point many folks have missed > is that the marking has to stay on the call all the way to the UAS. > > We also need a marking that tells us that the call has been location routed. > > > At one point, the way this worked was a call was marked urn:service:sos > until it was location routed, but that marking is lost after it was. I > think we need to know, after it's location routed, that it's (still) an > emergency call. > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortel.com] > Sent: Wednesday, March 01, 2006 11:40 AM > To: ecrit@ietf.org > Subject: [Ecrit] Definition of "emergency identifier" > > draft-ietf-ecrit-requirements-05 has the following definition for > "emergency identifier": > > Emergency identifier: The numerical and/or text identifier which is > supplied by a user or a user device, which identifies the call as > an emergency call and is translated into an emergency address, > useful for call routing and completion of the emergency call. > > The problem I see here is the phrase "is translated into". That would be > true for a URN in the Request-URI, but doesn't work for one in the To: > header field. My first suggestion is to terminate the definition after > "... which identifies the call as an emergency call." The alternative is > to go on to say "... and triggers emergency call routing procedures > possibly including mapping of the caller's location to an emergency > address.". > > Tom Taylor > > > > _______________________________________________ > 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 Wed Mar 01 16:31:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEYvM-0006ul-0K; Wed, 01 Mar 2006 16:31:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEYvK-0006tU-Uk for ecrit@ietf.org; Wed, 01 Mar 2006 16:31:54 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEYvK-0006Wc-J0 for ecrit@ietf.org; Wed, 01 Mar 2006 16:31:54 -0500 Received: from lion.cs.columbia.edu (IDENT:g2Te7eJNNtemIWomh7W7q9dYtXtGfDE3@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k21LVqeg021859 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT) for ; Wed, 1 Mar 2006 16:31:52 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k21LVpjN001070 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 1 Mar 2006 16:31:52 -0500 Message-ID: <440612C2.70204@cs.columbia.edu> Date: Wed, 01 Mar 2006 16:31:46 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'ecrit@ietf.org'" 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, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Ecrit] draft-rosen-sos-phonebcp 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: , Errors-To: ecrit-bounces@ietf.org I'm delighted to see this draft be written - it fills one of the major open work items that ECRIT, in my opinion, needs to address. One trivial item: It's a URN, not urn. The latter is what you may need when the emergency service fails. > It is desirable for the endpoint to do the mapping from location to > PSAP URI. This will allow for a fallback map to be know. It is > desirable for the first active signaling element (first hop proxy for > SIP) to do an [ecrit] mapping as well, as this will be the freshest > and most up-to-date URI of the appropriate PSAP. If the device > included a PSAP URI from fallback mapping in the SIP INVITE, the > first SIP element SHOULD do its mapping and use this result to > forward the message towards the PSAP. The fallback mapping's purpose > is in case the SIP element's mapping failed, the element would have a > route already in the message, just not one that is the freshest. I think this can be clarified significantly. I don't see, for example, why a proxy would have a "fresher" URI. (I've written about my concerns regarding the need for a DHCP solution elsewhere.) This all seems fairly simple: A UA that does resolution gets a new mapping whenever the mapping expires or the UA moves out of the coverage region specified in the mapping response (see the LoST draft). Thus, a simple version of 6.2 is: -- begin send-text --- User agents that can obtain location information MUST perform the mapping from location information to PSAP URI using [LoST]. The mapping is performed whenever the UA acquires new location information that is outside the bounds of the current PSAP coverage region specified in the LoST response or the time-to-live value of that response has expired. To deal with old user agents that predate this specification and with UAs that do not have access to their own location data, proxies that recognize a call as an emergency call that is not marked as such (see Section XXX) or where the request URI is a service:sos URN MUST also perform this mapping. A UA MUST perform a mapping when placing an emergency call. If the mapping protocol does not return an answer within 500 ms and the UA has cached a PSAP URI from the mapping operation described above, the UA MUST use that cached PSAP URI value to place a call. -- end send-text -- It seems to be that we want to make this process as simple and predictable as possible, removing deployment variability. I don't want the equivalent of "I thought *you* were going to take care of this". In a separate thread on the SIPPING list, there is a discussion on the evils of SHOULD; this applies here as well, not just in this paragraph. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 01 17:03:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZPQ-0004Rd-79; Wed, 01 Mar 2006 17:03:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEZPO-0004Pu-Bw for ecrit@ietf.org; Wed, 01 Mar 2006 17:02:58 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEZPN-0008BP-3W for ecrit@ietf.org; Wed, 01 Mar 2006 17:02:58 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 01 Mar 2006 14:02:56 -0800 X-IronPort-AV: i="4.02,157,1139212800"; d="scan'208"; a="411459293:sNHT30726644" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k21M2u7T015612; Wed, 1 Mar 2006 14:02:56 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 14:02:56 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.14]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 1 Mar 2006 14:02:55 -0800 Message-Id: <4.3.2.7.2.20060301155720.0286b530@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 01 Mar 2006 16:02:54 -0600 To: Henning Schulzrinne , "'ecrit@ietf.org'" From: "James M. Polk" Subject: Re: [Ecrit] draft-rosen-sos-phonebcp In-Reply-To: <440612C2.70204@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 01 Mar 2006 22:02:55.0680 (UTC) FILETIME=[E4E01400:01C63D7B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: ecrit-bounces@ietf.org At 04:31 PM 3/1/2006 -0500, Henning Schulzrinne wrote: >I'm delighted to see this draft be written - it fills one of the major >open work items that ECRIT, in my opinion, needs to address. 2+ years of discussion and 3 days of writing will get you an ID (sometimes)... We should have written this a looong time ago. >One trivial item: It's a URN, not urn. There are a few lower case acronyms and words that ought to be uppercase, including a few "shoulds" and "musts". We'll fix that in the next version. >The latter is what you may need when the emergency service fails. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 02 00:36:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEgTd-0000op-VM; Thu, 02 Mar 2006 00:35:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FEgTd-0000nq-5w for ecrit@ietf.org; Thu, 02 Mar 2006 00:35:49 -0500 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FEgTa-0003pX-Tz for ecrit@ietf.org; Thu, 02 Mar 2006 00:35:49 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 23:35:46 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 01 Mar 2006 23:35:46 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Mar 2006 23:35:45 -0600 Message-ID: From: "Winterbottom, James" To: Date: Wed, 1 Mar 2006 23:35:44 -0600 Subject: RE: [Ecrit] draft-rosen-sos-phonebcp 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 02 Mar 2006 05:35:45.0706 (UTC) FILETIME=[277908A0:01C63DBB] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] draft-rosen-sos-phonebcp Thread-Index: AcY9e+nPOq7F0yqjQhSqa2B8TcfIkwACD0mg X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Errors-To: ecrit-bounces@ietf.org Hi Guys, Not a bad effort at all, good job. A few things: I am not sure where this should be put, but I do think that it is relevant. In the western world call volumes made from mobiles are fast approach and in many places exceeding the call volumes made from wireline devices. For emergency calls the volumes are generally even, that is 50% of emergency calls are placed from mobile devices. The number of geodetic shape types that can be used to provide providing data, and subsequently displayed back at a PSAP are currently very limited.=20 Section 2. It would be good to point out that the steps list are for an IP based call. These steps are not strictly true for conventional calling devices. In section 4. I would be interested to understand where the 100ms and 500ms numbers came from. If this based on standards or empirical work it would be good to quote the source.=20 Same section I think that it would be very beneficial to add that a coarse location may be quite satisfactory for routing, and that a more precise location can be acquired for display and dispatch. Also in general the more precise the location, the longer it takes to generate and acquire. In section 6 First line grammar.. is expected To be In Section 6.1 I can't let this one slip sorry. If the device is mobile a by-reference mechanism will more than likely be faster than a by-value mechanism, and if any network assistance data is required it will always be faster as the device will not need to proxy requests. I recommend a change to this wording to something along the lines of "Where location is known, or can be determined quickly to a suitable level of precision then by-value...". As calling rates for mobile devices continue to climb by-value will become harder to provide ahead of time. Cheers James ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 03 02:39:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF4tA-00040h-ES; Fri, 03 Mar 2006 02:39:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FF4t7-0003vS-QX for ecrit@ietf.org; Fri, 03 Mar 2006 02:39:45 -0500 Received: from 67.254.241.83.in-addr.dgcsystems.net ([83.241.254.67] helo=smtp.dgcsystems.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FF4t2-0000cJ-9D for ecrit@ietf.org; Fri, 03 Mar 2006 02:39:45 -0500 Received: from MISAN ([217.13.240.136]) by smtp.dgcsystems.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 3 Mar 2006 08:39:38 +0100 From: "Gunnar Hellstrom" To: "Henning Schulzrinne" Date: Fri, 3 Mar 2006 08:39:38 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: X-OriginalArrivalTime: 03 Mar 2006 07:39:38.0721 (UTC) FILETIME=[A04EDD10:01C63E95] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: Arnoud van Wijk , ecrit@ietf.org, Gregg Vanderheiden Subject: [Ecrit] Words around text communication in draft-ietf-ecrit-requirements-05.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: , Errors-To: ecrit-bounces@ietf.org This is a good document. I have a couple of minor comments on the language around the usage of the text medium in emergency services. The draft uses the term "text messaging" as a common term for real-time text and instant messaging. I suggest to use "text communication" or plainly "text" when we mean both forms of using text. In emergency services it has shown to be extremely important to use real-time conversational communication forms whenever possible. Messaging is important but so easily causes delays, misunderstanding, confusion and stress that disturbs the emergency support. The possibility to see what the other person is typing while it is typed and be able to interrupt or give brief comments underway is essential for efficient handling of emergency communication. Real-time text gives that opportunity. The opportunity to use the communication medium you are used to from everyday life is another essential requirement. Both real-time text and text messaging are used in everyday life. Therefore it seems reasonable to describe use of both real-time text and text messaging. Therefore, I have a couple of suggestions for modifications: A-In 1. Introduction+++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------- Users of both voice-centric (telephone-like) and non voice type services (e.g. text messaging for hearing disabled users, (RFC 3351 Users of both voice-centric (telephone-like) and non voice type services (e.g. text communication for hearing disabled users, (RFC 3351 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ B.--- In 4. High level requirements ++++++++++++++++++++++++++++++++++++++++ ------------------------------ Re4. Multiple Modes: Multiple communication modes, such as audio, video and text messaging MUST be supported (i.e. implemented in the protocol, though not necessarily used). Re4. Multiple Modes: Multiple communication modes, such as audio, video and text MUST be supported (i.e. implemented in the protocol, though not necessarily used in all calls). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you read the whole surrounding text you will see that it merges well and gives a proper description for both types of text communication. Thanks Gunnar ---------------------------------------------------------------------------- - Gunnar Hellstrom, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, March 02, 2006 9:50 PM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: I-D ACTION:draft-ietf-ecrit-requirements-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-05.txt Pages : 30 Date : 2006-3-2 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-ietf-ecrit-requirements-05.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 03 12:53:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFET0-0003yH-BZ; Fri, 03 Mar 2006 12:53:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFESz-0003uw-76 for ecrit@ietf.org; Fri, 03 Mar 2006 12:53:25 -0500 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FFEFA-00069u-Uz for ecrit@ietf.org; Fri, 03 Mar 2006 12:39:10 -0500 X-VirusChecked: Checked X-Env-Sender: kamran.aquil@mitretek.org X-Msg-Ref: server-10.tower-128.messagelabs.com!1141407547!2844038!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [66.10.26.57] Received: (qmail 23792 invoked from network); 3 Mar 2006 17:39:07 -0000 Received: from mtk-news1.mitretek.org (HELO mtk-news1.mitretek.org) (66.10.26.57) by server-10.tower-128.messagelabs.com with SMTP; 3 Mar 2006 17:39:07 -0000 Received: from email1.mitretek.org (email1.mitretek.org [172.16.49.40]) by mtk-news1.mitretek.org (8.12.10/8.12.10) with ESMTP id k23Hd6Qc015511 for ; Fri, 3 Mar 2006 12:39:06 -0500 (EST) 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: Fri, 3 Mar 2006 12:39:06 -0500 Message-ID: <88C80871CC296F438124F37C5656BDAFCA5010@email1.mitretek.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Ecrit Digest, Vol 14, Issue 4 Thread-Index: AcY+4/9zxrpC9RYWTcOc2aCDxicOJQABEPvQ From: "Aquil, Kamran" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2a76bcd37b1c8a21336eb0a1ea6bbf48 Subject: [Ecrit] RE: Ecrit Digest, Vol 14, Issue 4 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: , Errors-To: ecrit-bounces@ietf.org =20 Replacing "Text Messaging" with "Text" would indeed be a better replacement. Text messaging sounds more like Instant Messaging ( Yahoo IM, AOL and MSN) only. Replacing it with "TEXT" would eliminate the ambiguity between Instant and Short Message Service (SMS) and encompass both services Kamran Aquil Mitretek System =20 =20 -----Original Message----- From: ecrit-request@ietf.org [mailto:ecrit-request@ietf.org]=20 Sent: Friday, March 03, 2006 12:00 PM To: ecrit@ietf.org Subject: Ecrit Digest, Vol 14, Issue 4 Send Ecrit mailing list submissions to ecrit@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/ecrit or, via email, send a message with subject or body 'help' to ecrit-request@ietf.org You can reach the person managing the list at ecrit-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Ecrit digest..." Today's Topics: 1. Words around text communication in draft-ietf-ecrit-requirements-05.txt (Gunnar Hellstrom) ---------------------------------------------------------------------- Message: 1 Date: Fri, 3 Mar 2006 08:39:38 +0100 From: "Gunnar Hellstrom" Subject: [Ecrit] Words around text communication in draft-ietf-ecrit-requirements-05.txt To: "Henning Schulzrinne" Cc: Arnoud van Wijk , ecrit@ietf.org, Gregg Vanderheiden Message-ID: Content-Type: text/plain; charset=3D"us-ascii" This is a good document. I have a couple of minor comments on the language around the usage of the text medium in emergency services. The draft uses the term "text messaging" as a common term for real-time text and instant messaging. I suggest to use "text communication" or plainly "text" when we mean both forms of using text. In emergency services it has shown to be extremely important to use real-time conversational communication forms whenever possible. Messaging is important but so easily causes delays, misunderstanding, confusion and stress that disturbs the emergency support. The possibility to see what the other person is typing while it is typed and be able to interrupt or give brief comments underway is essential for efficient handling of emergency communication. Real-time text gives that opportunity. The opportunity to use the communication medium you are used to from everyday life is another essential requirement. Both real-time text and text messaging are used in everyday life. Therefore it seems reasonable to describe use of both real-time text and text messaging. Therefore, I have a couple of suggestions for modifications: A-In 1. Introduction+++++++++++++++++++++++++++++++++++++++++++++++++++++ ------------------------------- Users of both voice-centric (telephone-like) and non voice type services (e.g. text messaging for hearing disabled users, (RFC 3351 Users of both voice-centric (telephone-like) and non voice type services (e.g. text communication for hearing disabled users, (RFC 3351 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++ B.--- In 4. High level requirements ++++++++++++++++++++++++++++++++++++++++ ------------------------------ Re4. Multiple Modes: Multiple communication modes, such as audio, video and text messaging MUST be supported (i.e. implemented in the protocol, though not necessarily used). Re4. Multiple Modes: Multiple communication modes, such as audio, video and text MUST be supported (i.e. implemented in the protocol, though not necessarily used in all calls). ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++ If you read the whole surrounding text you will see that it merges well and gives a proper description for both types of text communication. Thanks Gunnar ------------------------------------------------------------------------ ---- - Gunnar Hellstrom, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, March 02, 2006 9:50 PM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: I-D ACTION:draft-ietf-ecrit-requirements-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-05.txt Pages : 30 Date : 2006-3-2 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-ietf-ecrit-requirements-05.txt ------------------------------ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit End of Ecrit Digest, Vol 14, Issue 4 ************************************ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 03 17:04:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFIOC-0003lO-9s; Fri, 03 Mar 2006 17:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFHlY-0000qd-Qi for ecrit@ietf.org; Fri, 03 Mar 2006 16:24:48 -0500 Received: from [199.117.205.100] (helo=ns2.sccx.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFHPE-0006R5-6h for ecrit@ietf.org; Fri, 03 Mar 2006 16:01:45 -0500 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] Best Current Practice for Communications Services insupport of Emergency Calling X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Fri, 3 Mar 2006 15:01:37 -0600 Message-ID: <422D410BD61FC04185076AD99AA7207A016B0648@inilmx01.lgmt.trdo> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Best Current Practice for Communications Services insupport of Emergency Calling Thread-Index: AcY7q3UCNyC5bIHhRCWPJ1877Is1RwDVtavg From: "McCalmont, Patti" To: "Tschofenig, Hannes" , X-OriginalArrivalTime: 03 Mar 2006 21:01:39.0940 (UTC) FILETIME=[AACA2A40:01C63F05] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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: , Errors-To: ecrit-bounces@ietf.org What a great start to our Best Current Practice document. Thanks for taking the initiative to get it started. I have a few comments: Page 2 - "3. User device includes location indication in the call set-up Messaging" This would be a good place to clarify location indication as follows "3. User device includes location indication (by reference or by value) in the call set-up messaging" As a quick overview for a typical Ethernet connected telephone using SIP signaling: o the phone would get location from the DHCP server, L7 server or network access Server when it boots. o It would use "urn:service:sos" as the URI of an emergency call. o It would put its location in the SIP INVITE and forward the call to its first hop proxy. So anywhere it talks about getting the location it could be changed to "location indication", perhaps a definition up front along with the first usage would help. For devices that operate on a network where the network operator does not control the specification of every device connected to the network, DHCP [or L7] MUST be supported on the network. There are many references to DHCP [or L7]. I would suggest changing these to, a mechanism must be supported to provide the Location Indication to the device. There are other methods being proposed for obtaining location and that should really be up to the access network. I don't disagree that we should provide some of the options that are available. It is desirable that location information be periodically refreshed. For devices which are not expected to roam, refreshing on the order of once per day is recommended. For devices which roam, refresh of location should be more frequent, with the frequency related to the mobility of the device. There can be instances in which a device is aware of when it moves, for example when it changes access points. When this type of event occurs, the device should refresh its location. For mobile devices, if by reference is not used, there needs to be a lot of consideration to traffic on the network to refresh the location. Consider the millions of mobile devices out there and the impact to all the servers in the path that must refresh the mobile user's location, say every 5 minutes. The real question that may need to be asked is, is it necessary to refresh location or only when needed, like invoking a service that requires location? Section 6.1 "It is RECOMMENDED that location by-value is used by the device to convey location during emergency calling." I don't believe we can make this recommendation without doing some traffic studies. I also don't agree with this recommendation as location by reference has a lot of value as well. Patti -----Original Message----- From: Tschofenig, Hannes [mailto:hannes.tschofenig@siemens.com]=20 Sent: Monday, February 27, 2006 8:44 AM To: ecrit@ietf.org Subject: [Ecrit] Best Current Practice for Communications Services insupport of Emergency Calling Hi all,=20 here is another draft: Best Current Practice for Communications Services in support of Emergency Calling http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-00.txt =20 Requesting help in an emergency using a communications device such as a telephone or mobile is an accepted practice in most of the world. As communications devices increasingly utilize the Internet to interconnect and communicate, users will continue to expect to use such devices to request help, regardless of whether or not they communicate using IP. The emergency response community will have to upgrade their facilities to support the wider range of communications services, but cannot be expected to handle wide variation in device and service capability. The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This memo describes best current practice on how devices and services should use such standards to reliably make emergency calls Ciao Hannes _______________________________________________ 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 Sun Mar 05 11:07:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFvlF-0002Hi-1W; Sun, 05 Mar 2006 11:07:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FFvlD-0002D8-Pu for ecrit@ietf.org; Sun, 05 Mar 2006 11:07:07 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FFvlC-0001w2-IG for ecrit@ietf.org; Sun, 05 Mar 2006 11:07:07 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k25G73W4009018 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 5 Mar 2006 11:07:06 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v746.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ecrit@ietf.org From: Henning Schulzrinne Date: Sun, 5 Mar 2006 11:07:01 -0500 X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Ecrit] draft-ietf-ecrit-service-urn-01 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: , Errors-To: ecrit-bounces@ietf.org I have submitted an update to the service URN draft; you can find the HTML version at http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service- urn-01.html I believe it incorporates the comments received so far. Major changes include: - registration of services - description of service feature tag - security considerations - description of alternatives considered, as an appendix - DDDS description I now consider the document complete; there are no open issues listed. However, I'd like feedback on the DDDS description, as it makes certain choices. In particular, it assumes that various configuration protocols, such as DHCP and SIP configuration, will provide a domain name that provides a NAPTR record. The advantage of this approach is that a DHCP response doesn't have to include a long list of service mapping protocols, with preferences and other data, particularly if different services are hosted at different servers. There would likely be a separate definition for an ENUM service for the mapping protocol, but that doesn't quite fit into the scope of this draft and warrants a separate document. My suggestion would be to last-call the document after the IETF meeting, giving an opportunity for discussion at the ECRIT meeting. In order to better prepare for the meeting discussion, I'd appreciate if folks could read the document. It's short... Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 05 16:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG13h-0005cn-TO; Sun, 05 Mar 2006 16:46:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FG13g-0005WH-MF for ecrit@ietf.org; Sun, 05 Mar 2006 16:46:32 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FG13f-0002p7-Ar for ecrit@ietf.org; Sun, 05 Mar 2006 16:46:32 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k25LkSl05941 for ; Sun, 5 Mar 2006 16:46:28 -0500 (EST) Received: from [127.0.0.1] ([47.130.17.3] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 5 Mar 2006 16:46:28 -0500 Message-ID: <440B5C30.7040604@nortel.com> Date: Sun, 05 Mar 2006 16:46:24 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Mar 2006 21:46:28.0098 (UTC) FILETIME=[41E20620:01C6409E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ecrit] draft-taylor-ecrit-security-requirements-03.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: , Errors-To: ecrit-bounces@ietf.org I have submitted an update to the ECRIT Security Requirements document. Changes from the previous version include: -- new section for attacks relating to the use of the emergency identifier (i.e., the service URN) -- reordering of presentation of attacks to put emphasis on mass attacks -- incorporation of comments received from Spencer Dawkins and Hannes Tschofenig. I think this is ready to be taken up as a Working Group item. Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 06 05:31:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGD03-0007xX-0G; Mon, 06 Mar 2006 05:31:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGD01-0007xP-RJ for ecrit@ietf.org; Mon, 06 Mar 2006 05:31:33 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGD01-0003Gv-8o for ecrit@ietf.org; Mon, 06 Mar 2006 05:31:33 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 6 Mar 2006 02:31:31 -0800 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: Mon, 6 Mar 2006 02:31:30 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750461F489@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ECRIT -06 editing change log for new requirements draft version - all sections Thread-Index: AcZBBpdWtFeIAJR/T7mS6cNDJsOwCA== From: "Roger Marshall" To: "ECRIT" , "Tschofenig, Hannes" , "Marc Linser" X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 Cc: Subject: [Ecrit] ECRIT -06 editing change log for new requirements draft version - all sections 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: , Errors-To: ecrit-bounces@ietf.org ECRIT WG: Change log to accompany latest version of ECRIT requirements draft, , once it gets posted by the RFC editor. Editing based on Henning's redlined observations, ECRIT list-server email, and the editor's own reading: An assortment of important, yet minor changes in grammar and wording - these were not all documented in this change log, but will show up within a diff report against -05. The following log does seek to document noteable changes, based on issues/comments and based on general readability/consistency of the information. Changes: 2. Re5:[Ed. Broke apart Re5 into two separate requirements as below (Re5X will get renumbered as well in the next draft version)] Re5. Alternate Mapping Sources: The mapping protocol=20 MUST implement a mechanism that allows for the retrieval of mapping=20 information from different sources. Motivation: This provides the possibility of having available=20 alternative sources of mapping information when the normal source is=20 unavailable or unreachable. Re5X. Differences of Currency in Mapping Sources:=20 For alternate mapping, differences in currency between mapping data=20 contained within mapping sources SHOULD be minimized. Motivation: Alternative sources of mapping data may not have been=20 created or updated with the same set of information within the same=20 timeframe. 3. Re6: Reworded. [CHANGE FROM: Re6. Incremental Deployment: The ECRIT mapping=20 protocol MUST return URIs that are usable by a standard signaling=20 protocol (i.e., without special emergency extensions) unless an error is returned. Motivation: The format of the output returned by the mapping protocol=20 is in a standard format for communication protocol. For example, it should=20 return something SIP specific (e.g. URI), that any SIP capable phone=20 would be able to use if used in a SIP context. Special purpose URIs=20 would not be understood by "legacy" SIP devices since they do not=20 have knowledge about the mapping protocol, and therefore are not to be=20 used. ] [CHANGE TO: Re6. Mapping Result Usability: The ECRIT mapping=20 protocol MUST return a URI (or URIs) that are usable within a standard=20 signaling protocol (i.e., without special emergency extensions). Motivation: For example, a SIP specific URI returned by the mapping=20 protocol, needs to be usable within any SIP capable phone in a SIP=20 initiated emergency call. This is in contrast to a "special purpose" URI,=20 which may not be recognizable within a legacy SIP device. 4. Re7. [Ed. Relocated requirement Re7 to end of mapping section.] 5. Lo1-Lo4, Lo7 moved to end of Mapping Protocol section, (relabeled all sections) 6. Id2., Emergency Identifier section: [Change FROM: Id2. Universal Identifier Resolution: Where multiple=20 emergency service types exist, the mapping protocol MUST support=20 (i.e. implement, though not necessarily use) the individual treatment of each emergency identifier used, based on the specific type of=20 emergency help requested. ] [Change TO: Id2. Emergency identifier resolution: Where=20 multiple emergency service identifiers exist, there MUST be a mechanism to=20 differentiate each emergency identifier used, based on the=20 specific type of emergency help requested. ] 7. Id4. Removed the following requirement, since it isn't a protocol requirement, renumber section. [Removed following text: Id4. Emergency Identifier-based Marking: User=20 agents, proxies, and other network elements that process signaling=20 associated with emergency calls SHOULD be configured to recognize a=20 reasonable selection of logical emergency identifiers as a means to=20 initiate emergency marking. Motivation: Since user devices roam, emergency identifiers may vary=20 from region to region. It is therefore important that a network entity be=20 able to perform mapping and/or call routing within the context of its own=20 point of origin rather than relying on non-local logical emergency=20 identifiers as the only basis for emergency marking of calls. ] 8. Id12.=20 [Removed requirement, duplicate requirement with Id8.=20 Id12. Translation of emergency dial-strings: The SIP UA SHOULD translate both home and visited emergency dial-strings into a universal emergency identifier. ] 9. Section 7, Mapping Protocol, removed the following paragraph, since this was not mapping protocol specific. [Removed following text: Note that this case relies on an architecture where the call is=20 effectively routed to a copy of the database, rather than having some=20 non-SIP protocol query the database. ] 10. Section 7, Mapping Protocol, removed the following paragraph, since it is not required to specify the mapping protocol. [Removed following text: The problem at hand is more difficult to resolve than that for traditional=20 web or email services. In this case, the emergency caller only dialed an=20 emergency identifier, and depending on the location, any one of several=20 thousand PSAPs around the world could be appropriate PSAP. In=20 addition, there may be a finer resolution of routing (which the caller isn't=20 aware of), which results in a particular "accredited" PSAP (i.e. one run by local authorities) answering to call. (Many PSAPs are run by private=20 entities. For example, universities and corporations with large campuses=20 often have their own emergency response centers.) ] 11. Ma2., Mapping Protocol requirements, (section 7, con't). [Removed following text, since it is stated more clearly already in Ma4.: Ma2. Mapping redirection: The mapping protocol MUST=20 support (i.e. implement for use) redirection functionality, since in some=20 cases, an initial mapping may provide a single URL for a large geographic=20 area. Redirection is needed to then re-invokes the mapping protocol on=20 a different database to obtain another URL for a more resolute ESRP or=20 PSAP, which covers a smaller area. Motivation: The more local the mapping output is, the more favorable=20 (in most cases) the likely outcome will be for the emergency caller. ] 12. Ma5. [Removed following Motivation text, since it added no new information. Motivation: In response to a mapping request, a server will normally provide a URI or set of URIs for contacting the appropriate PSAP. ] 13. Ma13.=20 [Removed requirement and motivation text, since location updates are not supplied by the mapping protocol: Ma13. Location Updates: The mapping protocol MUST=20 support (i.e. implement, though not necessarily use) the ability to provide=20 location updates. Mapping services should implement the mechanisms to=20 provide updated location. Motivation: Updated location information may have an impact on PSAP=20 routing. In some cases it may be possible to redirect that call to a more=20 appropriate PSAP (some device measurement techniques provide quick=20 (i.e. early), but imprecise "first fix" location). ] 14. Ma17. [Change FROM: Ma17. Pervasive Mapping: The mapping protocol MUST support (i.e.=20 implement for use) the ability of the mapping function to be=20 invoked at any time, including while an emergency call is in=20 process. ] [Change TO: Ma17. Any time mapping: The mapping protocol MUST=20 support (i.e. implement for use) the ability of the=20 mapping function to be invoked at any time, including=20 while an emergency call is in process and before an=20 emergency call. ] 15. Ma19. [Change FROM: Ma19. Single URI Scheme: The mapping protocol MAY return multiple=20 URIs, though it SHOULD return only one URI per scheme, so that=20 clients are not required to select among different targets for the=20 same contact protocol. ] [Change TO: Ma19. Single URI per contact protocol: Though the mapping protocol=20 supports the return of multiple URIs, it SHOULD return only one URI per=20 contact protocol, so that clients are not required to select among different targets=20 for the same contact protocol. ] 16. Ma23.=20 [Removed requirement, since it's purpose is not sufficiently explained, through examples, etc.: Ma23. Support for location alias: The mapping protocol=20 MUST support (i.e. implement, though not necessarily use) one or more=20 aliases for a specific location entry. Motivation: It should be possible to relate one entry to another and be able to determine which is the "primary" entry and which is the alias. =20 The result of aliasing is always that mapping from the primary or any of the aliases is the same. ] 17. Ma24. [Removed requirement, since it is addressed in the now reworded Ma17 "Any time mapping". Ma24. Pre-call mapping for fallback: The mapping=20 protocol MUST support (i.e. implement, though not necessarily use)=20 LCMS queries prior to making an emergency call. ] [Appended the below motivation text onto Ma17, the "Any time mapping" requirement. Motivation: Used as a fallback mechanism only, if a LCMS query fails=20 at emergency call time, it may be advantageous to have prior knowledge=20 of the PSAP URI. This prior knowledge would be obtained by performing=20 an LCMS query at any time prior to an emergency call. ] 18. Reworded the following original paragraph to make it fit the mapping protocol section: [Change FROM: There are two basic architectures described for translating an=20 emergency identifier into the appropriate PSAP emergency address. =20 We refer to these as caller-based and mediated. ] [Change TO: There are two basic approaches to invoking a mapping service. We=20 refer to these as caller-based and mediated. In each case, the mapping=20 client initiates a request to a mapping server via a mapping protocol. =20 A proposed mapping protocol is outlined in the document=20 I-D.hardie-ecrit-lost. ] 19. Some cleanup of the use of "Universal emergency identifier" vs. "dial string", etc. 20. Incorporate Gunnar Hellstrom's recommended text changes ("text messaging" to "text communication", etc.) 21. Modify definition for term, "Emergency Identifier" as follows (per Taylor comment, plus an added sentence to contrast to a universal emergency identifier): [Change FROM: Emergency identifier: The numerical and/or text identifier which is supplied by a user or a user device, which identifies the call as an emergency call and is translated into an emergency address, useful for call routing and completion of the emergency call. ] [Change TO: Emergency identifier: The numerical and/or text=20 identifier which is supplied by a user or a user device, which=20 identifies the call as an emergency call. A universal emergency=20 identifier is an example of an emergency identifier. ] [end] -Roger Marshall _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 06 05:31:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGD08-00081s-5O; Mon, 06 Mar 2006 05:31:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGD06-00081j-BP for ecrit@ietf.org; Mon, 06 Mar 2006 05:31:38 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGD05-0003H2-Ul for ecrit@ietf.org; Mon, 06 Mar 2006 05:31:38 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 6 Mar 2006 02:31:37 -0800 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: RE: [Ecrit] Definition of "emergency identifier" Date: Mon, 6 Mar 2006 02:31:36 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750461F48A@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Definition of "emergency identifier" Thread-Index: AcY9XfUSBhSdrDqTRzCGwrE1bb4B8QDo3b3A From: "Roger Marshall" To: "Tom-PT Taylor" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 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: , Errors-To: ecrit-bounces@ietf.org Tom: I've gone ahead and truncated the paragraph, as suggested (see forthcoming change log for -06 version of the requirements draft).=20 Roger. >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@nortel.com]=20 >Sent: Wednesday, March 01, 2006 10:28 AM >To: br@brianrosen.net >Cc: ecrit@ietf.org >Subject: Re: [Ecrit] Definition of "emergency identifier" > >I absolutely agree with the first requirement -- I raised that=20 >issue myself. I also raised the point that the marker may have=20 >to be present on signalling messages subsequent to the INVITE. > >That said, do people agree with my proposal to truncate the=20 >definition of emergency marking after the words: "... which=20 >identifies the call as an emergency call." > >Brian Rosen wrote: >> This is part of the problem, but not the whole problem. >>=20 >> I agree we need to have some kind of marking that identifies an=20 >> emergency call. I think this marking has to be applied at any point=20 >> where an entity recognizes that it is an emergency call. The point=20 >> many folks have missed is that the marking has to stay on=20 >the call all the way to the UAS. >>=20 >> We also need a marking that tells us that the call has been=20 >location routed. >>=20 >>=20 >> At one point, the way this worked was a call was marked=20 >> urn:service:sos until it was location routed, but that=20 >marking is lost=20 >> after it was. I think we need to know, after it's location routed,=20 >> that it's (still) an emergency call. >>=20 >> Brian >>=20 >> -----Original Message----- >> From: Tom-PT Taylor [mailto:taylor@nortel.com] >> Sent: Wednesday, March 01, 2006 11:40 AM >> To: ecrit@ietf.org >> Subject: [Ecrit] Definition of "emergency identifier" >>=20 >> draft-ietf-ecrit-requirements-05 has the following definition for=20 >> "emergency identifier": >>=20 >> Emergency identifier: The numerical and/or text=20 >identifier which is >> supplied by a user or a user device, which identifies=20 >the call as >> an emergency call and is translated into an emergency address, >> useful for call routing and completion of the emergency call. >>=20 >> The problem I see here is the phrase "is translated into".=20 >That would=20 >> be true for a URN in the Request-URI, but doesn't work for=20 >one in the To: >> header field. My first suggestion is to terminate the=20 >definition after=20 >> "... which identifies the call as an emergency call." The=20 >alternative=20 >> is to go on to say "... and triggers emergency call routing=20 >procedures=20 >> possibly including mapping of the caller's location to an emergency=20 >> address.". >>=20 >> Tom Taylor >>=20 >>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit >>=20 >>=20 >>=20 > > >_______________________________________________ >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 Mon Mar 06 05:31:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGD0E-00086Q-Dj; Mon, 06 Mar 2006 05:31:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGD0D-00086I-CA for ecrit@ietf.org; Mon, 06 Mar 2006 05:31:45 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGD0B-0003HA-S5 for ecrit@ietf.org; Mon, 06 Mar 2006 05:31:45 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Mon, 6 Mar 2006 02:31:43 -0800 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: RE: [Ecrit] RE: Ecrit Digest, Vol 14, Issue 4 Date: Mon, 6 Mar 2006 02:31:42 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750461F48B@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Ecrit Digest, Vol 14, Issue 4 Thread-Index: AcY+4/9zxrpC9RYWTcOc2aCDxicOJQABEPvQAIZsQzA= From: "Roger Marshall" To: "Aquil, Kamran" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 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: , Errors-To: ecrit-bounces@ietf.org Gunnar's suggested change has been incorporated. Thanks. Roger Marshall. =20 >-----Original Message----- >From: Aquil, Kamran [mailto:kamran.aquil@mitretek.org]=20 >Sent: Friday, March 03, 2006 9:39 AM >To: ecrit@ietf.org >Subject: [Ecrit] RE: Ecrit Digest, Vol 14, Issue 4 > >=20 >Replacing "Text Messaging" with "Text" would indeed be a=20 >better replacement. Text messaging sounds more like Instant=20 >Messaging ( Yahoo IM, AOL and MSN) only. Replacing it with=20 >"TEXT" would eliminate the ambiguity between Instant and Short=20 >Message Service (SMS) and encompass both services > > > >Kamran Aquil >Mitretek System > >=20 > >=20 > > >-----Original Message----- >From: ecrit-request@ietf.org [mailto:ecrit-request@ietf.org] >Sent: Friday, March 03, 2006 12:00 PM >To: ecrit@ietf.org >Subject: Ecrit Digest, Vol 14, Issue 4 > >Send Ecrit mailing list submissions to > ecrit@ietf.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/ecrit >or, via email, send a message with subject or body 'help' to > ecrit-request@ietf.org > >You can reach the person managing the list at > ecrit-owner@ietf.org > >When replying, please edit your Subject line so it is more=20 >specific than >"Re: Contents of Ecrit digest..." > > >Today's Topics: > > 1. Words around text communication in > draft-ietf-ecrit-requirements-05.txt (Gunnar Hellstrom) > > >---------------------------------------------------------------------- > >Message: 1 >Date: Fri, 3 Mar 2006 08:39:38 +0100 >From: "Gunnar Hellstrom" >Subject: [Ecrit] Words around text communication in > draft-ietf-ecrit-requirements-05.txt >To: "Henning Schulzrinne" >Cc: Arnoud van Wijk , ecrit@ietf.org, Gregg > Vanderheiden >Message-ID: >Content-Type: text/plain; charset=3D"us-ascii" > >This is a good document. > >I have a couple of minor comments on the language around the=20 >usage of the text medium in emergency services. > >The draft uses the term "text messaging" as a common term for=20 >real-time text and instant messaging. >I suggest to use "text communication" or plainly "text" when=20 >we mean both forms of using text. > > >In emergency services it has shown to be extremely important=20 >to use real-time conversational communication forms whenever possible. >Messaging is important but so easily causes delays,=20 >misunderstanding, confusion and stress that disturbs the=20 >emergency support. >The possibility to see what the other person is typing while=20 >it is typed and be able to interrupt or give brief comments=20 >underway is essential for efficient handling of emergency=20 >communication. Real-time text gives that opportunity. > >The opportunity to use the communication medium you are used=20 >to from everyday life is another essential requirement. Both=20 >real-time text and text messaging are used in everyday life.=20 >Therefore it seems reasonable to describe use of both=20 >real-time text and text messaging. > > >Therefore, I have a couple of suggestions for modifications: > > > >A-In 1. >Introduction+++++++++++++++++++++++++++++++++++++++++++++++++++++ >------------------------------- > Users of both voice-centric (telephone-like) and non voice type > services (e.g. text messaging for hearing disabled users, (RFC 3351 > > > Users of both voice-centric (telephone-like) and non voice type > services (e.g. text communication for hearing disabled users, (RFC >3351 >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >+++++++++ >+++ > > >B.--- In 4. High level requirements >++++++++++++++++++++++++++++++++++++++++ >------------------------------ >Re4. Multiple Modes: Multiple communication modes, such as audio, > video and text messaging MUST be supported (i.e. implemented in > the protocol, though not necessarily used). > >and "in all calls" inserted last.-> > >Re4. Multiple Modes: Multiple communication modes, such as audio, > video and text MUST be supported (i.e. implemented in > the protocol, though not necessarily used in all calls). >+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >+++++++++ >++++ > >If you read the whole surrounding text you will see that it=20 >merges well and gives a proper description for both types of=20 >text communication. > > >Thanks >Gunnar > >--------------------------------------------------------------- >--------- >---- >- >Gunnar Hellstrom, Omnitor >gunnar.hellstrom@omnitor.se >Mob: +46 708 204 288 >Phone: +46 8 556 002 03 >www.omnitor.se > > >-----Original Message----- >From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >Sent: Thursday, March 02, 2006 9:50 PM >To: i-d-announce@ietf.org >Cc: ecrit@ietf.org >Subject: I-D ACTION:draft-ietf-ecrit-requirements-05.txt > > >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. >This draft is a work item of the Emergency Context Resolution=20 >with Internet Technologies Working Group of the IETF. > > Title : Requirements for Emergency Context Resolution >with Internet >Technologies > Author(s) : H. Schulzrinne, R. Marshall > Filename : draft-ietf-ecrit-requirements-05.txt > Pages : 30 > Date : 2006-3-2 > >This document enumerates requirements for emergency calls=20 >placed by the public using voice-over-IP (VoIP) and general=20 >Internet multimedia systems, where Internet protocols are used=20 >end-to-end. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requiremen ts-05.txt > > > > > > >------------------------------ > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit > > >End of Ecrit Digest, Vol 14, Issue 4 >************************************ > >_______________________________________________ >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 Mar 07 02:40:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWnf-0004AB-EO; Tue, 07 Mar 2006 02:40:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FGWne-00049b-IV for ecrit@ietf.org; Tue, 07 Mar 2006 02:40:06 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FGWZm-0004d4-Qg for ecrit@ietf.org; Tue, 07 Mar 2006 02:25:47 -0500 Received: from s010600095b9792b5.vc.shawcable.net ([70.79.6.118] helo=[192.168.0.101]) by dns.aliantmedia.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.52) id 1FGWZl-0007aC-UF for ecrit@ietf.org; Tue, 07 Mar 2006 01:25:46 -0600 Message-ID: <440D3577.3060202@ntt-at.com> Date: Mon, 06 Mar 2006 23:25:43 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Ecrit] [Comments on ECRIT Requirement] 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: , Errors-To: ecrit-bounces@ietf.org I haven't read the draft since version 02 and it definitely reads much better. Also I haven't compared my comments to what Roger recently posted as an upcoming changes, so I do apologize if I am repeating something here. Anyhow, here are my comments and questions. 1. Wording seem to lack consistency in the following requirements although, I believe they meant to mean the same -> MUST implement(not necessarily use) Re 7. MUST implement(not necessarily use) Lo 1, Lo7. MUST implement Lo 2, Lo 3, Id2. MUST support(i.e required to implement though not required to use.) I think there was more, but I think it's better to be consistency with the wording. 2. I found the following statement in Lo 3's to be rather unclear. "The protocol MUST support(i.e. must implement in the protocol, though not necessarily use) a mechanism to indicate that a location or a part of a location is known to not exist" It's not clear what is said by "location is known to not exist". Is it trying to address the situation where address which is non-existent in the real world is in the request? or is it simply trying to address situation where the location in the request is non-existent in the location database that mapping entity references(Possibly due to new street being built but propagation has not been completed or simply the request is phony?). I think it's the latter that we are trying to address here, but may be the requirement is trying to address both cases. 3. Confusion in IdN Is universal emergency identifier in Id1 and universal identifier in Id10 different? If they are the same, two requirements seem to be stating the same thing. 4. What's the difference between emergency marking and emergency identifier? Looking at the terminology, they seem to indicate the same thing. I guess this is what Tom was pointing out.. If the text from "translated.. " is removed from the terminology section, I don't think the confusion will occur, but may be Emergency identifier instead of marking should be used to be consistent with the terminology used. 5. I know that most likely candidate for the mapping protocol is SIP, but I thought that the mapping protocol is supposed to support other protocol as well. If my understanding is correct, it's odd to see SIP specific requirement seen in Id7 as well as Id12. It's really not a big deal, but they seemed out of place. 6. Id12 seems to cover Id7. 7. Ma5 and Ma7 both seem to say "MUST be able to return multiple PSAP URIs"? 8. Re7 seems to cover Ma13 and may be Ma17. 9. Ma24. "LCMS query" pops up only at this requirement. If we are to use this term here I think we should add "LCMS query" in terminology section. Regards Shida Schubert _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 09 08:51:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHLYU-00043e-9L; Thu, 09 Mar 2006 08:51:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FH5bh-0007FA-7m; Wed, 08 Mar 2006 15:50:05 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=cypress.neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FH5bf-0008Gz-EI; Wed, 08 Mar 2006 15:50:05 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k28Ko20e006048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Mar 2006 20:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FH5be-0002qk-Oy; Wed, 08 Mar 2006 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 08 Mar 2006 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-Mailman-Approved-At: Thu, 09 Mar 2006 08:51:49 -0500 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-06.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: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-06.txt Pages : 29 Date : 2006-3-8 This document enumerates requirements for the context resolution of 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-ietf-ecrit-requirements-06.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-ietf-ecrit-requirements-06.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-ietf-ecrit-requirements-06.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: <2006-3-8124800.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-requirements-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-requirements-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-8124800.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From ecrit-bounces@ietf.org Thu Mar 09 15:30:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRm6-0006YZ-Vo; Thu, 09 Mar 2006 15:30:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRm6-0006YM-7E for ecrit@ietf.org; Thu, 09 Mar 2006 15:30:18 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHRm5-0006jw-PN for ecrit@ietf.org; Thu, 09 Mar 2006 15:30:18 -0500 Received: (qmail invoked by alias); 09 Mar 2006 20:30:16 -0000 Received: from p54987083.dip.t-dialin.net (EHLO [192.168.2.101]) [84.152.112.131] by mail.gmx.net (mp020) with SMTP; 09 Mar 2006 21:30:16 +0100 X-Authenticated: #29516787 Message-ID: <44109056.1080203@gmx.net> Date: Thu, 09 Mar 2006 21:30:14 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Ecrit] [Fwd: I-D ACTION:draft-polk-dhc-uri-03.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: , Errors-To: ecrit-bounces@ietf.org fyi, -------- Original Message -------- Subject: I-D ACTION:draft-polk-dhc-uri-03.txt Date: Wed, 08 Mar 2006 02:50:02 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : A Dynamic Host Configuration Protocol Option for Requesting and Receiving Uniform Resource Identifiers Author(s) : J. Polk Filename : draft-polk-dhc-uri-03.txt Pages : 17 Date : 2006-3-7 This document defines a new Dynamic Host Configuration Protocol (DHC) Option to allow one or more URIs to be transmitted from a server to a client within one or more messages, and for one or more URIs, each with a unique purpose, to be specifically requested by a client of a server. Included in this Option is a purpose field to identify the type of URI being requested by the client, or the type of URI in the DHCP message from the server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-03.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-polk-dhc-uri-03.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-polk-dhc-uri-03.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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 09 15:30:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRmV-00072c-75; Thu, 09 Mar 2006 15:30:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHRmU-00072M-PV for ecrit@ietf.org; Thu, 09 Mar 2006 15:30:42 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHRmU-0006kK-C8 for ecrit@ietf.org; Thu, 09 Mar 2006 15:30:42 -0500 Received: (qmail invoked by alias); 09 Mar 2006 20:30:41 -0000 Received: from p54987083.dip.t-dialin.net (EHLO [192.168.2.101]) [84.152.112.131] by mail.gmx.net (mp043) with SMTP; 09 Mar 2006 21:30:41 +0100 X-Authenticated: #29516787 Message-ID: <44109070.7070002@gmx.net> Date: Thu, 09 Mar 2006 21:30:40 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Subject: [Ecrit] [Fwd: I-D ACTION:draft-ietf-sip-location-conveyance-02.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: , Errors-To: ecrit-bounces@ietf.org fyi, -------- Original Message -------- Subject: I-D ACTION:draft-ietf-sip-location-conveyance-02.txt Date: Wed, 08 Mar 2006 02:50:01 -0500 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org CC: sip@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Session Initiation Protocol Location Conveyance Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sip-location-conveyance-02.txt Pages : 33 Date : 2006-3-7 This document defines how the Session Initiation Protocol (SIP) conveys, or pushes, user location information from one SIP entity to another SIP entity. SIP Location Conveyance is always end to end, but sometimes the embedded location information can be acted upon by SIP Servers to direct where the message goes, based on where the user agent client is. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-02.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-ietf-sip-location-conveyance-02.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-ietf-sip-location-conveyance-02.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. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 09 19:33:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVZR-0001T1-Ek; Thu, 09 Mar 2006 19:33:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHVZR-0001Sw-1m for ecrit@ietf.org; Thu, 09 Mar 2006 19:33:29 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHVZP-0000Zm-ON for ecrit@ietf.org; Thu, 09 Mar 2006 19:33:29 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2006 16:33:27 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="313152540:sNHT30530020" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2A0XRGv001149 for ; Thu, 9 Mar 2006 16:33:27 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 16:33:27 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 16:33:26 -0800 Message-Id: <4.3.2.7.2.20060309182145.02e34670@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 18:33:25 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Mar 2006 00:33:26.0900 (UTC) FILETIME=[3F34E340:01C643DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [Ecrit] New ID describing where mapping can occur 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: , Errors-To: ecrit-bounces@ietf.org ECRIT WG I have written a series of new mapping IDs based on a core ID here: http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-events-00.txt which describes where ECRIT mapping can occur, with message flows involving several protocols. This ID does not have LoST shown yet, as the transport protocol hasn't been decided yet (HTTP or SOAP or ?), and is a stated open issue in the LoST ID. The ECRIT Mapping Events Abstract is here: Emergency calling is a localized event, requiring a caller to place an specially identified local emergency call to a Public Safety Answering Point (PSAP), while including the location of the caller in that signaling. The function of routing the set-up messaging to the appropriate PSAP is performed by a mapping function that binds a given location with one or more PSAP SIP(S)-URIs. This function is done by the ECRIT mapping protocol. This document analyzes when the ECRIT mapping protocol function can occur, and what general components are involved in that mapping. Comments to this ID are encouraged _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 09 20:03:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHW2F-0000Rf-KO; Thu, 09 Mar 2006 20:03:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHW2E-0000RS-EY for ecrit@ietf.org; Thu, 09 Mar 2006 20:03:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHW2D-0001XW-4i for ecrit@ietf.org; Thu, 09 Mar 2006 20:03:14 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2006 17:03:13 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="260926375:sNHT38995624" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2A12a1x015422 for ; Thu, 9 Mar 2006 17:03:12 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 17:03:03 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 17:03:03 -0800 Message-Id: <4.3.2.7.2.20060309184751.02ce4f08@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 19:02:35 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Mar 2006 01:03:03.0556 (UTC) FILETIME=[622D1440:01C643DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ecrit] New ID on ECRIT Mapping using SIP 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: , Errors-To: ecrit-bounces@ietf.org ECRIT WG I have written a new ID on how, as shown in the Mapping Events ID, a SIP UA can request that a ECRIT (LoST?) mapping take place based on the location information provided in the SIP REGISTER message when the device boots. This is assuming the UA learns its location (a rather fundamental assumption here). The UA then generates a PIDF-LO and includes that in a REGISTER Request message to the SIP Registrar. Upon receiving this message, the Registrar can perform a Mapping function using this WG's protocol to a mapping server, and return this PSAP-URI in the 200 OK to the REGISTER message to the registering UA. This provides a UA with a fallback PSAP URI that *can* be used *if* the ESRP fails in its mapping attempt. The Mapping Events ID has this message flow shown. This document leaves open the possibility to be expanded to include how a UA can, after boot time, re-lease/refresh the PSAP-URI through registration, and how the UA can use HTTP to openly query a Mapping aware server at any time to have the freshest PSAP-URI prior to the actual emergency call. SIP Registration refresh cycles are regularly on a 60 minute cycle, sometimes shorter, so the URI would be fairly fresh with this mechanism. This ID is invoking the use of the ECRIT mapping protocol, and is *not* competing with it. Here is the ID: http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-during-registration-00.txt Comments are welcome _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 09 20:22:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHWKN-00076a-EE; Thu, 09 Mar 2006 20:21:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHWKM-00070i-B8 for ecrit@ietf.org; Thu, 09 Mar 2006 20:21:58 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHWKL-000289-1C for ecrit@ietf.org; Thu, 09 Mar 2006 20:21:58 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2006 17:21:57 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="414201530:sNHT30650704" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2A1LrHT006242 for ; Thu, 9 Mar 2006 17:21:56 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 17:21:53 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 17:21:52 -0800 Message-Id: <4.3.2.7.2.20060309190527.02ed8ef8@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 19:21:42 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Mar 2006 01:21:53.0041 (UTC) FILETIME=[0366D010:01C643E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ecrit] New ID to get emergency dialsting into UA 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: , Errors-To: ecrit-bounces@ietf.org ECRIT This isn't really near the charter at the moment, but this is the most appropriate WG to have it individually for now. This ID calls for an extension into SIP to retrieve the appropriate "visited" emergency dialstring, ISO country code, and service identifier (for those countries with more than one emergency number) to a UA upon device registration and registration refresh. Here is the URL: http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt I have another new ID into DHCP on this topic because that technology is tied to the access infrastructure of where a UA is to be able to know which national emergency dialstrings are appropriate. The above is the SIP version of the DHCP ID here: http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-dialstring-option-00.txt I will be presenting the DHCP ID in that WG for now. The idea behind the ECRIT Dialstring ID is that this: When a device boots, it will learn its location (a fundamental assumption we need to make for a lot of all this to work). The UA generates a PIDF-LO and includes it in a SIP REGISTER Request message, seeking the appropriate dialstring for the UA's location. This will either be ignored or successfully returned in a 200 OK to the REGISTER request. The UA can have its digitmap modified based on this response, because it is just as likely a local user will dial for an emergency and not understand the UA is from another country, so the local (or "visited" from the UA's pov) numbers will have to function as expected. In both IDs I allow for just a country code to be downloaded to the UA. Comments to the ECRIT ID are welcome on this list. Please direct any DHCP-related comments to the DHC list, thus showing interest there. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 09 21:17:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXBy-0003d8-BV; Thu, 09 Mar 2006 21:17:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXBw-0003aA-Vl for ecrit@ietf.org; Thu, 09 Mar 2006 21:17:20 -0500 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHXBw-0004A3-Mk for ecrit@ietf.org; Thu, 09 Mar 2006 21:17:20 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 20:17:19 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 09 Mar 2006 20:17:19 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 20:17:18 -0600 Message-ID: From: "Winterbottom, James" To: "James M. Polk" , Date: Thu, 9 Mar 2006 20:17:17 -0600 Subject: RE: [Ecrit] New ID to get emergency dialsting into UA 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Mar 2006 02:17:18.0772 (UTC) FILETIME=[C1B11740:01C643E8] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] New ID to get emergency dialsting into UA Thread-Index: AcZD4UjMBc0+sDiLRbGtASzsn/UHVwABkc2Q X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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: , Errors-To: ecrit-bounces@ietf.org James, One thing that I have continually pointed out, and that seems to be continually ignored here is that any solution that requires location determination at boot time will be of use to less than 50% of people that make requests for emergency services. This figure increases to 60% when we talk valued added services. Mobile is a reality and is the norm, not the niche that it once was. Any solution therefore that makes a requirement on location being determined at boot time should be very carefully considered before it is adopted so as to avoid the necessity of deprecating it when implementation and deployment occurs. Cheers James >=20 > I have another new ID into DHCP on this topic because that technology is > tied to the access infrastructure of where a UA is to be able to know > which > national emergency dialstrings are appropriate. The above is the SIP > version of the DHCP ID here: >=20 > http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-dialstring- > option-00.txt >=20 >=20 > I will be presenting the DHCP ID in that WG for now. >=20 > The idea behind the ECRIT Dialstring ID is that this: >=20 > When a device boots, it will learn its location (a fundamental assumption > we need to make for a lot of all this to work). The UA generates a PIDF- > LO > and includes it in a SIP REGISTER Request message, seeking the appropriate > dialstring for the UA's location. This will either be ignored or > successfully returned in a 200 OK to the REGISTER request. The UA can > have > its digitmap modified based on this response, because it is just as likely > a local user will dial for an emergency and not understand the UA is from > another country, so the local (or "visited" from the UA's pov) numbers > will > have to function as expected. >=20 > In both IDs I allow for just a country code to be downloaded to the UA. >=20 > Comments to the ECRIT ID are welcome on this list. >=20 > Please direct any DHCP-related comments to the DHC list, thus showing > interest there. >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 09 21:34:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXSB-0001vY-GU; Thu, 09 Mar 2006 21:34:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXSA-0001vT-Fk for ecrit@ietf.org; Thu, 09 Mar 2006 21:34:06 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHXSA-0004Ms-1h for ecrit@ietf.org; Thu, 09 Mar 2006 21:34:06 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2006 18:34:06 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="313183217:sNHT34083652" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2A2Y5w3011622 for ; Thu, 9 Mar 2006 18:34:05 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 18:34:05 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 18:34:04 -0800 Message-Id: <4.3.2.7.2.20060309202457.03b9cc98@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 20:34:03 -0600 To: ecrit@ietf.org From: "James M. Polk" Subject: Re: [Ecrit] [Fwd: I-D ACTION:draft-ietf-sip-location-conveyance-02.txt] In-Reply-To: <44109070.7070002@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Mar 2006 02:34:04.0728 (UTC) FILETIME=[1949CB80:01C643EB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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: , Errors-To: ecrit-bounces@ietf.org Indeed, and notice the page count now (33). It was (74) for version -01, so I was busy editing. The other changes of note: - Limited the scope of this document to SIP conveyance, meaning only how SIP can push location information. removed PUBLISH (defered to Presence to address), SUBSCRIBE (pull), NOTIFY (pull)and REFER (grey area for now) from the solution - reduced emergency calling text to just a few paragraphs now that the ECRIT WG is taking most of that topic on. This will likely now be covered in the phoneBCP doc - greatly reduced the number of requirements in this version. Took out a lot of operational requirements, which also will be in the phoneBCP - changed the requirements groups from "UA-to-UA", "UA-to-Proxy", etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is being asked of each SIP element. - Removed the full SIP message examples. - completed the ABNF for the Location header, including a cid-url to point at a message body part to help in parsing for location. Yesterday I received a comment on how I can change the ABNF of the Location header further, part of which made sense immediately, the remainder makes this an open issue at this moment. Today I had a comment about more to do with the ABNF. - Deleted the call for a new 425 (Retry Location) response code, as it appears this can easily be used to spoof a UA into providing where it is inadvertently, even if the intent is legitimate by the UAC. There were a few other minor nits brought up to address. More comments are welcome, but PLEASE on the SIP List, as the chair there is questioning how interested folks are in this ID because of the lack of comments on the ID's home list; when in fact, many comments are made -> on other lists. At 09:30 PM 3/9/2006 +0100, Hannes Tschofenig wrote: >fyi, > >-------- Original Message -------- >Subject: I-D ACTION:draft-ietf-sip-location-conveyance-02.txt >Date: Wed, 08 Mar 2006 02:50:01 -0500 >From: Internet-Drafts@ietf.org >Reply-To: internet-drafts@ietf.org >To: i-d-announce@ietf.org >CC: sip@ietf.org > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Session Initiation Protocol Working Group >of the IETF. > > Title : Session Initiation Protocol Location Conveyance > Author(s) : J. Polk, B. Rosen > Filename : draft-ietf-sip-location-conveyance-02.txt > Pages : 33 > Date : 2006-3-7 > >This document defines how the Session Initiation Protocol (SIP) > conveys, or pushes, user location information from one SIP entity > to another SIP entity. SIP Location Conveyance is always end to > end, but sometimes the embedded location information can be acted > upon by SIP Servers to direct where the message goes, based on where > the user agent client is. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sip-location-conveyance-02.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-ietf-sip-location-conveyance-02.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-ietf-sip-location-conveyance-02.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. > > >_______________________________________________ >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 Mar 09 21:50:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXhj-0001lu-8L; Thu, 09 Mar 2006 21:50:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXhh-0001lm-Ga for ecrit@ietf.org; Thu, 09 Mar 2006 21:50:09 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHXhh-0004bL-5I for ecrit@ietf.org; Thu, 09 Mar 2006 21:50:09 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2006 18:50:09 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="1783707982:sNHT43300134" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2A2o725003432; Thu, 9 Mar 2006 18:50:08 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 18:50:03 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 18:50:02 -0800 Message-Id: <4.3.2.7.2.20060309203740.02678618@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 20:50:01 -0600 To: "Winterbottom, James" , From: "James M. Polk" Subject: RE: [Ecrit] New ID to get emergency dialsting into UA In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Mar 2006 02:50:02.0650 (UTC) FILETIME=[544117A0:01C643ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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: , Errors-To: ecrit-bounces@ietf.org James Location is not conveyed in the DHCP Option ID for a dialstring, so it doesn't need to be downloaded at device boot-time to have this DHCP option work. Tell me this, what mobile solution doesn't have a chance of knowing what country you're in? If DHCP isn't available, the UA can learn location any number of ways, build a PIDF-LO and transmit that to a SIP Registrar server to determine either an emergency dialstring here: http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt or a PSAP-URI. That's here: http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-during-registration-00.txt If you don't have location, you cannot tell responders how to get to you to give you help. The second ID above also starts discussing how a UA learns about mapping by using SIP SUBSCRIBE, HTTP or another fetch protocol. Little of this is limited to being done at boot time, and none of it is mandated to only be at boot time. I do not believe too many emergency calls will occur within seconds of boot-time, so there is time to get the necessary information. At 08:17 PM 3/9/2006 -0600, Winterbottom, James wrote: >James, > >One thing that I have continually pointed out, and that seems to be >continually ignored here is that any solution that requires location >determination at boot time will be of use to less than 50% of people >that make requests for emergency services. This figure increases to 60% >when we talk valued added services. Mobile is a reality and is the norm, >not the niche that it once was. Any solution therefore that makes a >requirement on location being determined at boot time should be very >carefully considered before it is adopted so as to avoid the necessity >of deprecating it when implementation and deployment occurs. > >Cheers >James > > > > > > > I have another new ID into DHCP on this topic because that technology >is > > tied to the access infrastructure of where a UA is to be able to know > > which > > national emergency dialstrings are appropriate. The above is the SIP > > version of the DHCP ID here: > > > > >http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-dialstring- > > option-00.txt > > > > > > I will be presenting the DHCP ID in that WG for now. > > > > The idea behind the ECRIT Dialstring ID is that this: > > > > When a device boots, it will learn its location (a fundamental >assumption > > we need to make for a lot of all this to work). The UA generates a >PIDF- > > LO > > and includes it in a SIP REGISTER Request message, seeking the >appropriate > > dialstring for the UA's location. This will either be ignored or > > successfully returned in a 200 OK to the REGISTER request. The UA can > > have > > its digitmap modified based on this response, because it is just as >likely > > a local user will dial for an emergency and not understand the UA is >from > > another country, so the local (or "visited" from the UA's pov) numbers > > will > > have to function as expected. > > > > In both IDs I allow for just a country code to be downloaded to the >UA. > > > > Comments to the ECRIT ID are welcome on this list. > > > > Please direct any DHCP-related comments to the DHC list, thus showing > > interest there. > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 09 21:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXjk-0003ls-DM; Thu, 09 Mar 2006 21:52:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHXjj-0003ln-F9 for ecrit@ietf.org; Thu, 09 Mar 2006 21:52:15 -0500 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHXjj-0004fD-4f for ecrit@ietf.org; Thu, 09 Mar 2006 21:52:15 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2A2qDgv001130 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 9 Mar 2006 21:52:13 -0500 (EST) In-Reply-To: <4.3.2.7.2.20060309190527.02ed8ef8@email.cisco.com> References: <4.3.2.7.2.20060309190527.02ed8ef8@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] New ID to get emergency dialsting into UA Date: Thu, 9 Mar 2006 21:52:03 -0500 To: "James M. Polk" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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: , Errors-To: ecrit-bounces@ietf.org James, thanks for all the draft contributions. I will pick on this one, however. My general concern is that there is a danger of having too many ways to do roughly the same thing. SIP and surrounding protocols already suffer from the problem and perception of having specs that approach the Manhattan phone book in size (and in the likelihood that somebody will read them cover-to- cover). The danger of having multiple ways to do the same thing is that implementors will implement a set with an empty intersection when clients and server meet. Plus, every new protocol and mechanism means more interoperability testing, more possible buffer overflows, dealing with contradictory information, non-uniform capabilities ("I can express X in mechanism A, but not in B") and more code foot print. We already have a SIP configuration mechanism, being discussed in SIPPING. Adding another special-purpose mechanism just for dial strings (or PSAPS URIs) seems sub-optimal. I think there was some general agreement that we'd like to avoid emergency-specific mechanisms. I believe we should take a minimalist approach - one mechanism per problem, universally implemented, and as generic as possible, with a strong preference to mechanisms that are useful beyond emergency calling (since that will speed their implementation and testing). I find the two proposals particularly unsatisfactory since they require knowledge of dial strings far beyond the natural expertise of the owner of the DHCP server or proxy. Your local Asterisk PBX owner that had it installed by Joe's Computer & Hair Salon isn't going to remember to change the dial string for Serbia when that location adopts 112. For dial strings, I believe the simplest mechanism already exists: - End system determines location, at least at the country level, e.g., through DHCP. (Works for geo or civic). - Invoke the mapping protocol, using the information maintained by people responsible for the information. In many cases, the end system has to do that anyway. Henning On Mar 9, 2006, at 8:21 PM, James M. Polk wrote: > ECRIT > > This isn't really near the charter at the moment, but this is the > most appropriate WG to have it individually for now. > > This ID calls for an extension into SIP to retrieve the appropriate > "visited" emergency dialstring, ISO country code, and service > identifier (for those countries with more than one emergency > number) to a UA upon device registration and registration refresh. > Here is the URL: > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency- > dialstring-00.txt > > I have another new ID into DHCP on this topic because that > technology is tied to the access infrastructure of where a UA is to > be able to know which national emergency dialstrings are > appropriate. The above is the SIP version of the DHCP ID here: > > http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency- > dialstring-option-00.txt > > I will be presenting the DHCP ID in that WG for now. > > The idea behind the ECRIT Dialstring ID is that this: > > When a device boots, it will learn its location (a fundamental > assumption we need to make for a lot of all this to work). The UA > generates a PIDF-LO and includes it in a SIP REGISTER Request > message, seeking the appropriate dialstring for the UA's location. > This will either be ignored or successfully returned in a 200 OK to > the REGISTER request. The UA can have its digitmap modified based > on this response, because it is just as likely a local user will > dial for an emergency and not understand the UA is from another > country, so the local (or "visited" from the UA's pov) numbers will > have to function as expected. > > In both IDs I allow for just a country code to be downloaded to the > UA. > > Comments to the ECRIT ID are welcome on this list. > > Please direct any DHCP-related comments to the DHC list, thus > showing interest there. > > _______________________________________________ > 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 Mar 09 22:15:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHY6B-0001Ro-4q; Thu, 09 Mar 2006 22:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHY6A-0001Rj-8L for ecrit@ietf.org; Thu, 09 Mar 2006 22:15:26 -0500 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHY69-0005Zp-SQ for ecrit@ietf.org; Thu, 09 Mar 2006 22:15:26 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 21:15:25 -0600 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Thu, 09 Mar 2006 21:15:25 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Mar 2006 21:15:24 -0600 Message-ID: From: "Winterbottom, James" To: "James M. Polk" , Date: Thu, 9 Mar 2006 21:15:22 -0600 Subject: RE: [Ecrit] New ID to get emergency dialsting into UA 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Mar 2006 03:15:24.0630 (UTC) FILETIME=[DF6CCF60:01C643F0] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: [Ecrit] New ID to get emergency dialsting into UA Thread-Index: AcZD7VhvRN9eDshSRcWW7fwc9nQvpQAAh5lQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 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: , Errors-To: ecrit-bounces@ietf.org James, I think that you have missed my point entirely. There is a huge difference between knowing your country, and knowing the ultimate destination of a call. All I am saying is that performing mapping at anytime other than call time makes the assumption that you are static and not mobile (unless all calls always go to the same address). Making this assumption requires that both are catered for, which adds complexity and infrastructure cost. Build one that supports both in exactly the same way.=20 Cheers James > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Friday, 10 March 2006 1:50 PM > To: Winterbottom, James; ecrit@ietf.org > Subject: RE: [Ecrit] New ID to get emergency dialsting into UA >=20 > James >=20 > Location is not conveyed in the DHCP Option ID for a dialstring, so it > doesn't need to be downloaded at device boot-time to have this DHCP option > work. >=20 > Tell me this, what mobile solution doesn't have a chance of knowing what > country you're in? >=20 > If DHCP isn't available, the UA can learn location any number of ways, > build a PIDF-LO and transmit that to a SIP Registrar server to determine > either an emergency dialstring here: >=20 > http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstrin g- > 00.txt >=20 > or a PSAP-URI. That's here: >=20 > http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-during- > registration-00.txt >=20 >=20 > If you don't have location, you cannot tell responders how to get to you > to > give you help. >=20 > The second ID above also starts discussing how a UA learns about mapping > by > using SIP SUBSCRIBE, HTTP or another fetch protocol. >=20 > Little of this is limited to being done at boot time, and none of it is > mandated to only be at boot time. >=20 > I do not believe too many emergency calls will occur within seconds of > boot-time, so there is time to get the necessary information. >=20 > At 08:17 PM 3/9/2006 -0600, Winterbottom, James wrote: >=20 >=20 > >James, > > > >One thing that I have continually pointed out, and that seems to be > >continually ignored here is that any solution that requires location > >determination at boot time will be of use to less than 50% of people > >that make requests for emergency services. This figure increases to 60% > >when we talk valued added services. Mobile is a reality and is the norm, > >not the niche that it once was. Any solution therefore that makes a > >requirement on location being determined at boot time should be very > >carefully considered before it is adopted so as to avoid the necessity > >of deprecating it when implementation and deployment occurs. > > > >Cheers > >James > > > > > > > > > > > > I have another new ID into DHCP on this topic because that technology > >is > > > tied to the access infrastructure of where a UA is to be able to know > > > which > > > national emergency dialstrings are appropriate. The above is the SIP > > > version of the DHCP ID here: > > > > > > > >http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-dialstring - > > > option-00.txt > > > > > > > > > I will be presenting the DHCP ID in that WG for now. > > > > > > The idea behind the ECRIT Dialstring ID is that this: > > > > > > When a device boots, it will learn its location (a fundamental > >assumption > > > we need to make for a lot of all this to work). The UA generates a > >PIDF- > > > LO > > > and includes it in a SIP REGISTER Request message, seeking the > >appropriate > > > dialstring for the UA's location. This will either be ignored or > > > successfully returned in a 200 OK to the REGISTER request. The UA can > > > have > > > its digitmap modified based on this response, because it is just as > >likely > > > a local user will dial for an emergency and not understand the UA is > >from > > > another country, so the local (or "visited" from the UA's pov) numbers > > > will > > > have to function as expected. > > > > > > In both IDs I allow for just a country code to be downloaded to the > >UA. > > > > > > Comments to the ECRIT ID are welcome on this list. > > > > > > Please direct any DHCP-related comments to the DHC list, thus showing > > > interest there. > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > >----------------------------------------------------------------------- -- > ----------------------- > >This message is for the designated recipient only and may > >contain privileged, proprietary, or otherwise private information. > >If you have received it in error, please notify the sender > >immediately and delete the original. Any unauthorized use of > >this email is prohibited. > >----------------------------------------------------------------------- -- > ----------------------- > >[mf2] ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 09 23:25:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZCG-0003Qb-B5; Thu, 09 Mar 2006 23:25:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHZCF-0003QS-0I for ecrit@ietf.org; Thu, 09 Mar 2006 23:25:47 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHZCE-0007J6-Dj for ecrit@ietf.org; Thu, 09 Mar 2006 23:25:46 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2006 20:25:45 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="414245612:sNHT33897004" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2A4PjGv029846; Thu, 9 Mar 2006 20:25:45 -0800 (PST) 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, 9 Mar 2006 20:25:45 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 20:25:45 -0800 Message-Id: <4.3.2.7.2.20060309220155.02e83378@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 22:25:44 -0600 To: "Winterbottom, James" , From: "James M. Polk" Subject: RE: [Ecrit] New ID to get emergency dialsting into UA In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Mar 2006 04:25:45.0206 (UTC) FILETIME=[B3159960:01C643FA] X-Spam-Score: 0.0 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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: , Errors-To: ecrit-bounces@ietf.org James I don't believe obtaining a country's emergency dialstring is that dynamic wrt changing locations. This DHCP Option doesn't include a client's location in the message to the client or to the server, so it is really the location of the infrastructure the client is attached to that is important when determining what the locally significant emergency dialstring is returned in to the request. Enterprise, SMB, DSL and Cable access infrastructures aren't mobile wrt UAs, it's UAs that can be mobile. This particular ID has nothing to do with LoST, BTW. At 09:15 PM 3/9/2006 -0600, Winterbottom, James wrote: >James, > >I think that you have missed my point entirely. >There is a huge difference between knowing your country, and knowing the >ultimate destination of a call. All I am saying is that performing >mapping at anytime other than call time makes the assumption that you >are static and not mobile (unless all calls always go to the same >address). Making this assumption requires that both are catered for, >which adds complexity and infrastructure cost. Build one that supports >both in exactly the same way. > >Cheers >James > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Friday, 10 March 2006 1:50 PM > > To: Winterbottom, James; ecrit@ietf.org > > Subject: RE: [Ecrit] New ID to get emergency dialsting into UA > > > > James > > > > Location is not conveyed in the DHCP Option ID for a dialstring, so it > > doesn't need to be downloaded at device boot-time to have this DHCP >option > > work. > > > > Tell me this, what mobile solution doesn't have a chance of knowing >what > > country you're in? > > > > If DHCP isn't available, the UA can learn location any number of ways, > > build a PIDF-LO and transmit that to a SIP Registrar server to >determine > > either an emergency dialstring here: > > > > >http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstrin >g- > > 00.txt > > > > or a PSAP-URI. That's here: > > > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-during- > > registration-00.txt > > > > > > If you don't have location, you cannot tell responders how to get to >you > > to > > give you help. > > > > The second ID above also starts discussing how a UA learns about >mapping > > by > > using SIP SUBSCRIBE, HTTP or another fetch protocol. > > > > Little of this is limited to being done at boot time, and none of it >is > > mandated to only be at boot time. > > > > I do not believe too many emergency calls will occur within seconds of > > boot-time, so there is time to get the necessary information. > > > > At 08:17 PM 3/9/2006 -0600, Winterbottom, James wrote: > > > > > > >James, > > > > > >One thing that I have continually pointed out, and that seems to be > > >continually ignored here is that any solution that requires location > > >determination at boot time will be of use to less than 50% of people > > >that make requests for emergency services. This figure increases to >60% > > >when we talk valued added services. Mobile is a reality and is the >norm, > > >not the niche that it once was. Any solution therefore that makes a > > >requirement on location being determined at boot time should be very > > >carefully considered before it is adopted so as to avoid the >necessity > > >of deprecating it when implementation and deployment occurs. > > > > > >Cheers > > >James > > > > > > > > > > > > > > > > > I have another new ID into DHCP on this topic because that >technology > > >is > > > > tied to the access infrastructure of where a UA is to be able to >know > > > > which > > > > national emergency dialstrings are appropriate. The above is the >SIP > > > > version of the DHCP ID here: > > > > > > > > > > > >http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency-dialstring >- > > > > option-00.txt > > > > > > > > > > > > I will be presenting the DHCP ID in that WG for now. > > > > > > > > The idea behind the ECRIT Dialstring ID is that this: > > > > > > > > When a device boots, it will learn its location (a fundamental > > >assumption > > > > we need to make for a lot of all this to work). The UA generates >a > > >PIDF- > > > > LO > > > > and includes it in a SIP REGISTER Request message, seeking the > > >appropriate > > > > dialstring for the UA's location. This will either be ignored or > > > > successfully returned in a 200 OK to the REGISTER request. The UA >can > > > > have > > > > its digitmap modified based on this response, because it is just >as > > >likely > > > > a local user will dial for an emergency and not understand the UA >is > > >from > > > > another country, so the local (or "visited" from the UA's pov) >numbers > > > > will > > > > have to function as expected. > > > > > > > > In both IDs I allow for just a country code to be downloaded to >the > > >UA. > > > > > > > > Comments to the ECRIT ID are welcome on this list. > > > > > > > > Please direct any DHCP-related comments to the DHC list, thus >showing > > > > interest there. > > > > > > > > _______________________________________________ > > > > Ecrit mailing list > > > > Ecrit@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > >----------------------------------------------------------------------- >-- > > ----------------------- > > >This message is for the designated recipient only and may > > >contain privileged, proprietary, or otherwise private information. > > >If you have received it in error, please notify the sender > > >immediately and delete the original. Any unauthorized use of > > >this email is prohibited. > > > >----------------------------------------------------------------------- >-- > > ----------------------- > > >[mf2] > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 10 00:21:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHa3s-0008Fg-4T; Fri, 10 Mar 2006 00:21:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHa3p-0008Fb-Uc for ecrit@ietf.org; Fri, 10 Mar 2006 00:21:09 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHa3o-0000Yy-9I for ecrit@ietf.org; Fri, 10 Mar 2006 00:21:09 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2006 21:21:07 -0800 X-IronPort-AV: i="4.02,180,1139212800"; d="scan'208"; a="313213090:sNHT34784564" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k2A5L7Gv018690; Thu, 9 Mar 2006 21:21:07 -0800 (PST) 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, 9 Mar 2006 21:21:06 -0800 Received: from jmpolk-wxp.cisco.com ([10.89.16.70]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 9 Mar 2006 21:21:06 -0800 Message-Id: <4.3.2.7.2.20060309222705.031da950@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Mar 2006 23:21:05 -0600 To: Henning Schulzrinne From: "James M. Polk" Subject: Re: [Ecrit] New ID to get emergency dialsting into UA In-Reply-To: References: <4.3.2.7.2.20060309190527.02ed8ef8@email.cisco.com> <4.3.2.7.2.20060309190527.02ed8ef8@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 10 Mar 2006 05:21:06.0409 (UTC) FILETIME=[6EACF590:01C64402] X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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: , Errors-To: ecrit-bounces@ietf.org Henning Comments in-line (with a **H-I-G-H**L-E-V-E-L** of sarcasm in all below ;-) At 09:52 PM 3/9/2006 -0500, Henning Schulzrinne wrote: >James, > >thanks for all the draft contributions. > >I will pick on this one, however. you picked on more than one, btw... ;-) > My general concern is that there is >a danger of having too many ways to do roughly the same thing. fair comment - so maybe there is more than one way to do something. But two is more than one, and yet not as complex as 5 or 10. I wrote all these to have a discussion, not to be attacked as if I believe every one of them MUST BE IMPLEMENTED.... I'm not that outta touch. Maybe one resonates with a certain type of infrastructure organization, i.e. Cable or DSL or Enterprise or SMB or... >SIP >and surrounding protocols already suffer from the problem and >perception of having specs that approach the Manhattan phone book in >size (and in the likelihood that somebody will read them cover-to- cover). that's cuz it's so extensible.... didn't you design that into SIP? ;-) >The danger of having multiple ways to do the same thing is that >implementors will implement a set with an empty intersection when >clients and server meet. Plus, every new protocol and mechanism means >more interoperability testing, more possible buffer overflows, >dealing with contradictory information, non-uniform capabilities ("I >can express X in mechanism A, but not in B") and more code foot print. OK, fine, so are you suggesting we don't talk about any other way of doing something than the one, obvious choice? Learning a locally significant dialstring doesn't have such a protocol right now, so there isn't "one" choice to make. That said, and you're done this many times yourself, I wrote these IDs to cause discussion. Do I think all of them are going to become PSs? I really don't think so; but I have been wrong about a lot of things and I'm not sure really which of these ideas are going to resonate and which ones aren't. Is anyone really sure until discussion occurs? These IDs could serve the purpose of focus for that discussion. >We already have a SIP configuration mechanism, being discussed in >SIPPING. Adding another special-purpose mechanism just for dial >strings (or PSAPS URIs) seems sub-optimal. I think there was some >general agreement that we'd like to avoid emergency-specific mechanisms. Well, how do you suggest this very real problem get fixed? It's real and some areas are calling for a solution. >I believe we should take a minimalist approach - one mechanism per >problem, Voice signaling has more than one protocol, so why haven't all others stopped begin developed beause SIP is the *obvious* choice going forward? I really don't believe any of the others have stopped being developed, have they? Even MGCP is getting extended. I know H.248 is; as is H.323.... >universally implemented, Everything involving ECRIT is not a proven technology because it has not been coded yet, not been deployed yet, not been used yet, not been stress tested yet, why are we so willing to reduce our possible solutions to one offering? This is interesting, but nothing, and I mean ZERO of what I've proposed is an alternate to LoST. Nothing I wrote replaces or does anything more than *invoke* LoST, does it? learning a locally significant dialstring and LoST retrieving a PSAP-URI are two different problems. Now, should SIP be used to download that dialstring, eh... I'm even skeptical. But that doesn't mean some might not say "boom, there it is, the perfect answer to our problems".... Or are we better killing all ideas that might offer another way of doing mapping before they are really ever thought of? That might sound a little too much like narrowmindedness ;-) and preventing innovative thought processes, and I'm too stubborn to sit in the corner because someone doesn't want me to ask questions and propose alternate theories this early in the game. >and as generic as possible, with a >strong preference to mechanisms that are useful beyond emergency >calling (since that will speed their implementation and testing). DHCP is useful beyond emergency services, and might have predated emergency services ;-) The ID proposes an extention to an existing protocol, and I don't agree that is a reason to kill the idea. >I find the two proposals particularly unsatisfactory since they >require knowledge of dial strings far beyond the natural expertise of >the owner of the DHCP server or proxy. Well.... I don't think the owner of a DHCP server has the natural expertise of location either, particularly in either format (GPS or civic), but I wrote a document about that, which is an RFC now. You did too, and it's going to become an RFC. Where did Joe learn about GPS to the point he could implement a system that depends on it? How does he know XML? >Your local Asterisk PBX owner >that had it installed by Joe's Computer & Hair Salon isn't going to >remember to change the dial string for Serbia when that location >adopts 112. These nationally specific dialstring changes don't happen overnight... they sometimes take a decade or more years. So I think that's fairly safe. Plus, it will only take one emergency call to Joe to fix the dialstring in that Serbian location before it is corrected and stable for the next few decades, or till dialstrings are no longer relevant. Any system that can't take one failed call is one that isn't worth designing in the first place... >For dial strings, I believe the simplest mechanism already exists: > >- End system determines location, at least at the country level, >e.g., through DHCP. (Works for geo or civic). > >- Invoke the mapping protocol, hmmm.... invokve the mapping protocol.... to a URL right? Any how did that UA learn this URI of a mapping server? Is this address hardcoded? hmmm.... what dialstring is whichever user to use to call for help that will be understood by that UA so that it includes location in the INVITE? If my phone is in France and someone else uses it to call for emergency help, what number are they likely to use? How did my phone, from the land of 911=help, know that "other" number meant the same thing? I am going to South Africa the week after IETF. 911 doesn't work down there. What number does? My GSM phone will work cuz it did last year. I don't believe this area of your response is answering my questions or solving the problem at hand. What do I dial and how did I learn that? >using the information maintained by >people responsible for the information. In many cases, the end system >has to do that anyway. lots of questions to your comments, and it's funny how vendors want to do things just a little differently than designers, which is a little differently than customers want, because not everyone is the same or wants things exactly the same way. >Henning > > > >On Mar 9, 2006, at 8:21 PM, James M. Polk wrote: > >>ECRIT >> >>This isn't really near the charter at the moment, but this is the >>most appropriate WG to have it individually for now. >> >>This ID calls for an extension into SIP to retrieve the appropriate >>"visited" emergency dialstring, ISO country code, and service >>identifier (for those countries with more than one emergency >>number) to a UA upon device registration and registration refresh. >>Here is the URL: >> >>http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency- >>dialstring-00.txt >> >>I have another new ID into DHCP on this topic because that >>technology is tied to the access infrastructure of where a UA is to >>be able to know which national emergency dialstrings are >>appropriate. The above is the SIP version of the DHCP ID here: >> >>http://www.ietf.org/internet-drafts/draft-polk-dhc-emergency- >>dialstring-option-00.txt >> >>I will be presenting the DHCP ID in that WG for now. >> >>The idea behind the ECRIT Dialstring ID is that this: >> >>When a device boots, it will learn its location (a fundamental >>assumption we need to make for a lot of all this to work). The UA >>generates a PIDF-LO and includes it in a SIP REGISTER Request >>message, seeking the appropriate dialstring for the UA's location. >>This will either be ignored or successfully returned in a 200 OK to >>the REGISTER request. The UA can have its digitmap modified based >>on this response, because it is just as likely a local user will >>dial for an emergency and not understand the UA is from another >>country, so the local (or "visited" from the UA's pov) numbers will >>have to function as expected. >> >>In both IDs I allow for just a country code to be downloaded to the >>UA. >> >>Comments to the ECRIT ID are welcome on this list. >> >>Please direct any DHCP-related comments to the DHC list, thus >>showing interest there. >> >>_______________________________________________ >>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 Fri Mar 10 03:36:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHd6V-0006KX-Qt; Fri, 10 Mar 2006 03:36:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHd6H-0005Gh-Kj for ecrit@ietf.org; Fri, 10 Mar 2006 03:35:53 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHd3B-0006Bu-7y for ecrit@ietf.org; Fri, 10 Mar 2006 03:32:44 -0500 Received: (qmail invoked by alias); 10 Mar 2006 08:32:39 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp032) with SMTP; 10 Mar 2006 09:32:39 +0100 X-Authenticated: #29516787 Message-ID: <441139A6.1020306@gmx.net> Date: Fri, 10 Mar 2006 09:32:38 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Subject: [Ecrit] IETF#65 ECRIT Agenda 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: , Errors-To: ecrit-bounces@ietf.org Hi all, below you find a first proposal for the agenda. A few notes: - Our focus is on finishing ongoing work. We will discuss open issues with the req. and service urn draft. Tom has rewritten the threats draft as discussed during the interim meeting (see Tom's mail on this subject). - Then, we are going to discuss future work. These presentations aim to solicit feedback from the group whether a particular item should be added to the charter. We have listed a few items but we maybe have forgotten some others. Please let us know if you have more topics to discuss. Ciao Hannes ************************************************************ Emergency Context Resolution with Internet Technologies WG TUESDAY, March 21, 2006 0900-1130 Morning Session I ===================================================== CHAIRS: Hannes Tschofenig Marc Linsner AGENDA o Agenda Bashing / Current Status (Chairs, 15 min) o Requirements (Roger Marshall, 15 min) http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt Issues raised during WGLC o Security Threats Document (Tom Taylor, 15 min) Discussion of open issues o A Uniform Resource Name for Services (Henning Schulzrinne, 15 min) http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-01.txt Discussion of open issues o LoST: A Location-to-Service Translation Protocol (T. Hardie/A. Newton/H. Schulzrinne, 30 min) http://www.ietf-ecrit.org/cache/draft-hardie-ecrit-lost-00.txt Current status, open issues and next steps o Discussion about future work (All, 75 min) Emergency Context Routing of Internet Technologies Architecture Considerations http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch-considerations-02.txt Best Current Practice for Communications Services in support of Emergency Calling http://www.ietf.org/internet-drafts/draft-rosen-ecrit-phonebcp-00.txt Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency Calling http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-events-00.txt ECRIT Mapping During Session Initiation Protocol Registration http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-during-registration-00.txt Using the Session Initiation Protocol REGISTER Method To Obtain an Emergency Dialstring http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt A Dynamic Host Configuration Protocol Option for Requesting and Receiving Uniform Resource Identifiers http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-03.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 10 09:26:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHiZx-0001XV-8K; Fri, 10 Mar 2006 09:26:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHiZw-0001VK-4S for ecrit@ietf.org; Fri, 10 Mar 2006 09:26:52 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHiZv-00007w-Rj for ecrit@ietf.org; Fri, 10 Mar 2006 09:26:52 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2AEQjdA011041 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 10 Mar 2006 09:26:50 -0500 (EST) In-Reply-To: <4.3.2.7.2.20060309222705.031da950@email.cisco.com> References: <4.3.2.7.2.20060309190527.02ed8ef8@email.cisco.com> <4.3.2.7.2.20060309190527.02ed8ef8@email.cisco.com> <4.3.2.7.2.20060309222705.031da950@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8198B422-E2D4-4A3A-8FD1-CBE258104901@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] New ID to get emergency dialsting into UA Date: Fri, 10 Mar 2006 09:26:43 -0500 To: "James M. Polk" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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: , Errors-To: ecrit-bounces@ietf.org > > fair comment - so maybe there is more than one way to do > something. But two is more than one, and yet not as complex as 5 > or 10. I wrote all these to have a discussion, not to be attacked > as if I believe every one of them MUST BE IMPLEMENTED.... I'm not > that outta touch. Maybe one resonates with a certain type of > infrastructure organization, i.e. Cable or DSL or Enterprise or SMB > or... > Many, if not most, UAs will end up being deployed across different types of access networks. I have a Cisco 7960 phone at home... > > That said, and you're done this many times yourself, I wrote these > IDs to cause discussion. Do I think all of them are going to > become PSs? I really don't think so; but I have been wrong about a > lot of things and I'm not sure really which of these ideas are > going to resonate and which ones aren't. Is anyone really sure > until discussion occurs? > > These IDs could serve the purpose of focus for that discussion. > Having a concrete proposal is always helpful. Consider this to be part of the discussion you were asking for... > >> We already have a SIP configuration mechanism, being discussed in >> SIPPING. Adding another special-purpose mechanism just for dial >> strings (or PSAPS URIs) seems sub-optimal. I think there was some >> general agreement that we'd like to avoid emergency-specific >> mechanisms. > > Well, how do you suggest this very real problem get fixed? It's > real and some areas are calling for a solution. See below. > Where did Joe learn about GPS to the point he could implement a > system that depends on it? How does he know XML? He wouldn't. He'd fill out a web form with the street address. He probably managed to do that when filling out the form at eBay to place his last order for vintage toasters. > >> Your local Asterisk PBX owner >> that had it installed by Joe's Computer & Hair Salon isn't going to >> remember to change the dial string for Serbia when that location >> adopts 112. > > These nationally specific dialstring changes don't happen > overnight... they sometimes take a decade or more years. So I think > that's fairly safe. Plus, it will only take one emergency call to > Joe to fix the dialstring in that Serbian location before it is > corrected and stable for the next few decades, or till dialstrings > are no longer relevant. If this were the only option, we might have to live with this. I don't think it is. > > Any system that can't take one failed call is one that isn't worth > designing in the first place... > > >> For dial strings, I believe the simplest mechanism already exists: >> >> - End system determines location, at least at the country level, >> e.g., through DHCP. (Works for geo or civic). >> >> - Invoke the mapping protocol, > > hmmm.... invokve the mapping protocol.... to a URL right? Any how > did that UA learn this URI of a mapping server? Is this address > hardcoded? No. The LoST and URN drafts talk about discovery and propose mechanisms. They need to be fleshed out, but are fairly straightforward. > > hmmm.... what dialstring is whichever user to use to call for help > that will be understood by that UA so that it includes location in > the INVITE? > > If my phone is in France and someone else uses it to call for > emergency help, what number are they likely to use? How did my > phone, from the land of 911=help, know that "other" number meant > the same thing? If it knows its location, it got it along with the PSAP URI. > > I am going to South Africa the week after IETF. 911 doesn't work > down there. What number does? My GSM phone will work cuz it did > last year. As you may know, I've strenuously argued for the need to know both home and visited dial strings. There is no disagreement on that score, I think, just on mechanism. > > I don't believe this area of your response is answering my > questions or solving the problem at hand. What do I dial and how > did I learn that? Let me repeat what I wrote before in slightly more detail: (1) Determine LoST server URL, using the mechanisms described in the LoST and service URN drafts. (This may involve either DHCP or using the SIP AOR's domain, followed by a NAPTR lookup.) (2) Use LoST and provide rough location in either civic or geo (based on cell tower, DHCP civic or geo, etc.). (3) Obtain , as shown in the example in the LoST draft. A system that wants to do end-system resolution has to perform these steps in any event, so the additional effort is close to zero. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 10 09:53:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHizj-0004x1-Sb; Fri, 10 Mar 2006 09:53:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHizi-0004wu-Rh for ecrit@ietf.org; Fri, 10 Mar 2006 09:53:30 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHizh-0000b0-De for ecrit@ietf.org; Fri, 10 Mar 2006 09:53:30 -0500 Received: (qmail invoked by alias); 10 Mar 2006 14:53:27 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp001) with SMTP; 10 Mar 2006 15:53:27 +0100 X-Authenticated: #29516787 Message-ID: <441192E4.8010209@gmx.net> Date: Fri, 10 Mar 2006 15:53:24 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org, Marc Linser References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" 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: , Errors-To: ecrit-bounces@ietf.org Hi all, we have a charter item for an informational document describing the threats and security considerations. Tom has resently submitted another draft update that matches this charter item: http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-03.txt This document is the outcome of many discussions and the desire to change the content and scope of the document several times (originally from draft-tschofenig-ecrit-security-threats-00.txt, draft-tschofenig-ecrit-security-threats-01.txt, draft-taylor-ecrit-security-threats-00.txt, draft-taylor-ecrit-security-threats-01.txt, draft-taylor-ecrit-security-threats-02.txt to the most recent version draft-taylor-ecrit-security-threats-03.txt). Please speak for or against making draft-taylor-ecrit-security-threats-03.txt a working group item for the ECRIT working group. Deadline for responding to this hum is the 17th March 2006. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 10 11:11:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkCl-0002jt-1D; Fri, 10 Mar 2006 11:11:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHkCi-0002ja-Mw for ecrit@ietf.org; Fri, 10 Mar 2006 11:11:01 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHkCh-0003QC-8L for ecrit@ietf.org; Fri, 10 Mar 2006 11:11:00 -0500 Received: (qmail invoked by alias); 10 Mar 2006 16:10:58 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp022) with SMTP; 10 Mar 2006 17:10:58 +0100 X-Authenticated: #29516787 Message-ID: <4411A50A.8020400@gmx.net> Date: Fri, 10 Mar 2006 17:10:50 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] IETF#65 ECRIT Agenda References: <441139A6.1020306@gmx.net> In-Reply-To: <441139A6.1020306@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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: , Errors-To: ecrit-bounces@ietf.org Hi, I forgot to Henning's draft about "Location-to-URL Mapping Architecture and Framework" http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping-arch-00.txt Sorry. Ciao Hannes Hannes Tschofenig wrote: > Hi all, > > below you find a first proposal for the agenda. > > A few notes: > > - Our focus is on finishing ongoing work. We will discuss open issues > with the req. and service urn draft. Tom has rewritten the threats draft > as discussed during the interim meeting (see Tom's mail on this subject). > > - Then, we are going to discuss future work. These presentations aim to > solicit feedback from the group whether a particular item should be > added to the charter. We have listed a few items but we maybe have > forgotten some others. Please let us know if you have more topics to > discuss. > > Ciao > Hannes > > ************************************************************ > > Emergency Context Resolution with Internet Technologies WG > > TUESDAY, March 21, 2006 > > 0900-1130 Morning Session I > > ===================================================== > > CHAIRS: > > Hannes Tschofenig > Marc Linsner > > AGENDA > > > o Agenda Bashing / Current Status (Chairs, 15 min) > > > o Requirements (Roger Marshall, 15 min) > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt > > Issues raised during WGLC > > > o Security Threats Document (Tom Taylor, 15 min) > > Discussion of open issues > > > o A Uniform Resource Name for Services (Henning Schulzrinne, 15 min) > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-01.txt > > Discussion of open issues > > > o LoST: A Location-to-Service Translation Protocol > (T. Hardie/A. Newton/H. Schulzrinne, 30 min) > http://www.ietf-ecrit.org/cache/draft-hardie-ecrit-lost-00.txt > > Current status, open issues and next steps > > > o Discussion about future work (All, 75 min) > > Emergency Context Routing of Internet Technologies > Architecture Considerations > > http://www.ietf.org/internet-drafts/draft-polk-newton-ecrit-arch-considerations-02.txt > > > Best Current Practice for Communications Services in support of > Emergency Calling > http://www.ietf.org/internet-drafts/draft-rosen-ecrit-phonebcp-00.txt > > Analyzing ECRIT Mapping of a Location to an > Emergency URI for Emergency Calling > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-events-00.txt > > ECRIT Mapping During Session Initiation Protocol Registration > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-during-registration-00.txt > > > Using the Session Initiation Protocol REGISTER Method > To Obtain an Emergency Dialstring > > http://www.ietf.org/internet-drafts/draft-polk-ecrit-emergency-dialstring-00.txt > > > A Dynamic Host Configuration Protocol Option for > Requesting and Receiving Uniform Resource Identifiers > http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-03.txt > > > _______________________________________________ > 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 Fri Mar 10 16:58:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHpd0-0004Ua-F1; Fri, 10 Mar 2006 16:58:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHpcz-0004U6-8Q for ecrit@ietf.org; Fri, 10 Mar 2006 16:58:29 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FHpcx-000105-TZ for ecrit@ietf.org; Fri, 10 Mar 2006 16:58:29 -0500 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 k2ALwLIM004243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 10 Mar 2006 13:58:22 -0800 Received: from [129.46.225.88] (dhcp-campbell-31.qualcomm.com [129.46.225.88]) by magus.qualcomm.com (8.13.5/8.12.5/1.0) with ESMTP id k2ALwJmE013693; Fri, 10 Mar 2006 13:58:21 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <441192E4.8010209@gmx.net> References: <441192E4.8010209@gmx.net> Date: Fri, 10 Mar 2006 13:58:17 -0800 To: Hannes Tschofenig , ecrit@ietf.org, Marc Linser From: Ted Hardie Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: ecrit-bounces@ietf.org At 3:53 PM +0100 3/10/06, Hannes Tschofenig wrote: > >Please speak for or against making >draft-taylor-ecrit-security-threats-03.txt a working group item for the >ECRIT working group. > >Deadline for responding to this hum is the 17th March 2006. > I believe it is appropriate for this to be working group item. Ted Hardie _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 10 17:22:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHq0I-0002El-Oi; Fri, 10 Mar 2006 17:22:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FHq0G-0001wR-Pp for ecrit@ietf.org; Fri, 10 Mar 2006 17:22:32 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FHq0E-0002A4-Cj for ecrit@ietf.org; Fri, 10 Mar 2006 17:22:32 -0500 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] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Date: Fri, 10 Mar 2006 23:25:56 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C48CF@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Thread-Index: AcZEUvcnlo9KnEPbRbeymec0irm8TgAPqI/Q From: "Stastny Richard" To: "Hannes Tschofenig" , , "Marc Linser" X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: ecrit-bounces@ietf.org I hum for this i-D being a work group item =20 Richard Stastny ________________________________ Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Gesendet: Fr 10.03.2006 15:53 An: ecrit@ietf.org; Marc Linser Betreff: [Ecrit] Hum for "Security Threats and Requirements for = Emergency Call Marking and Mapping" Hi all, we have a charter item for an informational document describing the threats and security considerations. Tom has resently submitted another draft update that matches this charter item: http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-0= 3.txt This document is the outcome of many discussions and the desire to change the content and scope of the document several times (originally from draft-tschofenig-ecrit-security-threats-00.txt, draft-tschofenig-ecrit-security-threats-01.txt, draft-taylor-ecrit-security-threats-00.txt, draft-taylor-ecrit-security-threats-01.txt, draft-taylor-ecrit-security-threats-02.txt to the most recent version draft-taylor-ecrit-security-threats-03.txt). Please speak for or against making draft-taylor-ecrit-security-threats-03.txt a working group item for the ECRIT working group. Deadline for responding to this hum is the 17th March 2006. Ciao Hannes & Marc _______________________________________________ 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 Sat Mar 11 11:34:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI72j-00038Y-Fp; Sat, 11 Mar 2006 11:34:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI72i-00038T-3u for ecrit@ietf.org; Sat, 11 Mar 2006 11:34:12 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FI72g-0002A0-NO for ecrit@ietf.org; Sat, 11 Mar 2006 11:34:12 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Sat, 11 Mar 2006 08:34:02 -0800 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: RE: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Date: Sat, 11 Mar 2006 08:33:51 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750470658B@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Thread-Index: AcZEUrBqDOaa5YZ4SUO79Qr0LZL7igA1rlLw From: "Roger Marshall" To: "Hannes Tschofenig" , , "Marc Linser" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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: , Errors-To: ecrit-bounces@ietf.org I do Hum for making draft-taylor-ecrit-security-threats-03 an accepted ECRIT working group item. Roger Marshall.=20 >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Friday, March 10, 2006 6:53 AM >To: ecrit@ietf.org; Marc Linser >Subject: [Ecrit] Hum for "Security Threats and Requirements=20 >for Emergency Call Marking and Mapping" > >Hi all, > >we have a charter item for an informational document=20 >describing the threats and security considerations. > >Tom has resently submitted another draft update that matches=20 >this charter item: >http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security >-threats-03.txt > >This document is the outcome of many discussions and the=20 >desire to change the content and scope of the document several=20 >times (originally from draft-tschofenig-ecrit-security-threats-00.txt, >draft-tschofenig-ecrit-security-threats-01.txt, >draft-taylor-ecrit-security-threats-00.txt, >draft-taylor-ecrit-security-threats-01.txt, >draft-taylor-ecrit-security-threats-02.txt to the most recent=20 >version draft-taylor-ecrit-security-threats-03.txt). > >Please speak for or against making >draft-taylor-ecrit-security-threats-03.txt a working group=20 >item for the ECRIT working group. > >Deadline for responding to this hum is the 17th March 2006. > >Ciao >Hannes & Marc > >_______________________________________________ >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 Sat Mar 11 11:55:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI7Nl-00008u-7P; Sat, 11 Mar 2006 11:55:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FI7Nk-00008m-2R for ecrit@ietf.org; Sat, 11 Mar 2006 11:55:56 -0500 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FI7Ni-0002l9-RC for ecrit@ietf.org; Sat, 11 Mar 2006 11:55:56 -0500 Received: from [192.168.0.41] (pool-138-89-78-149.mad.east.verizon.net [138.89.78.149]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2BGtiL0020656 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 11 Mar 2006 11:55:45 -0500 (EST) In-Reply-To: <8C837214C95C864C9F34F3635C2A65750470658B@SEA-EXCHVS-2.telecomsys.com> References: <8C837214C95C864C9F34F3635C2A65750470658B@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Date: Sat, 11 Mar 2006 11:55:44 -0500 To: "Roger Marshall" X-Mailer: Apple Mail (2.746.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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: , Errors-To: ecrit-bounces@ietf.org Here's my hum: http://amasci.com/hum/avebury5.wav On Mar 11, 2006, at 11:33 AM, Roger Marshall wrote: > I do Hum for making draft-taylor-ecrit-security-threats-03 an accepted > ECRIT working group item. > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 13 03:21:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIiIr-0001Ji-JZ; Mon, 13 Mar 2006 03:21:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIiIq-0001Iz-HK for ecrit@ietf.org; Mon, 13 Mar 2006 03:21:20 -0500 Received: from wproxy.gmail.com ([64.233.184.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIiG9-0005Xh-AP for ecrit@ietf.org; Mon, 13 Mar 2006 03:18:34 -0500 Received: by wproxy.gmail.com with SMTP id i34so1128354wra for ; Mon, 13 Mar 2006 00:18:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=LSJGUSmGabEiz7uIaOZ9kgMZxQYuYNjQFs7giaTEQc/PTgCoL0NNSWhR2QL7zb0hWJv+16mBvW2xO/YmfMKkgnMWykJHQClcE7NZ68eMuc4wFm7hb8TqKMOB7MXR1KnvQZezGXYN+TfwET/o0DJss2kRQKrocN47cTv6o0RDA6Q= Received: by 10.35.107.20 with SMTP id j20mr714809pym; Mon, 13 Mar 2006 00:18:32 -0800 (PST) Received: by 10.35.19.12 with HTTP; Mon, 13 Mar 2006 00:18:32 -0800 (PST) Message-ID: Date: Mon, 13 Mar 2006 09:18:32 +0100 From: "Murugaraj Shanmugam" To: ecrit@ietf.org Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" In-Reply-To: MIME-Version: 1.0 References: <8C837214C95C864C9F34F3635C2A65750470658B@SEA-EXCHVS-2.telecomsys.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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="===============0846916651==" Errors-To: ecrit-bounces@ietf.org --===============0846916651== Content-Type: multipart/alternative; boundary="----=_Part_890_6614675.1142237912832" ------=_Part_890_6614675.1142237912832 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline i beleieve that the draft can be accepted as WG item ciao, Raj. On 3/11/06, Henning Schulzrinne wrote: > > Here's my hum: > > http://amasci.com/hum/avebury5.wav > > On Mar 11, 2006, at 11:33 AM, Roger Marshall wrote: > > > I do Hum for making draft-taylor-ecrit-security-threats-03 an accepted > > ECRIT working group item. > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > ------=_Part_890_6614675.1142237912832 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
 
i beleieve that the draft can be accepted as WG item
 
ciao,
Raj.

 
On 3/11/06, = Henning Schulzrinne <hgs@cs.c= olumbia.edu> wrote:
Here's my hum:

http://amasci.com/hum/avebury5.wav=

On Mar 11, 2006, at 11:33 AM, Roger Marshall wrote:

> I do Hu= m for making draft-taylor-ecrit-security-threats-03 an accepted
> ECR= IT working group item.
>

_____________________________________= __________
Ecrit mailing list
Ecrit@ietf.org<= /a>
https://www= 1.ietf.org/mailman/listinfo/ecrit

------=_Part_890_6614675.1142237912832-- --===============0846916651== 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 --===============0846916651==-- From ecrit-bounces@ietf.org Mon Mar 13 09:22:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FInwa-0002Kv-4b; Mon, 13 Mar 2006 09:22:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FInwY-0002Kq-N1 for ecrit@ietf.org; Mon, 13 Mar 2006 09:22:42 -0500 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FInwX-0008Iv-DY for ecrit@ietf.org; Mon, 13 Mar 2006 09:22:42 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k2DEMdc11727; Mon, 13 Mar 2006 09:22:39 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006031309223426849 ; Mon, 13 Mar 2006 09:22:34 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 13 Mar 2006 09:22:34 -0500 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: RE: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Date: Mon, 13 Mar 2006 09:22:33 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Thread-Index: AcZEUrCmxQV/4nIJQ1O9ZJ2z+d66gQCViJYA From: "Abbott, Nadine B" To: "Hannes Tschofenig" , , "Marc Linser" X-OriginalArrivalTime: 13 Mar 2006 14:22:34.0274 (UTC) FILETIME=[92310020:01C646A9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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: , Errors-To: ecrit-bounces@ietf.org Hannes and Marc, I believe that this document should be adopted as a working group item. This is an important issue, and there is valuable work here that needs to be supported by the working group. My thanks to the authors and contributors. Nadine (P.S. I think that the material that was removed at the last meeting was also of value, and hope that it can be input to future work some time.) =20 -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent: Friday, March 10, 2006 9:53 AM To: ecrit@ietf.org; Marc Linser Subject: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Hi all, we have a charter item for an informational document describing the threats and security considerations. Tom has resently submitted another draft update that matches this charter item: http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats- 03.txt This document is the outcome of many discussions and the desire to change the content and scope of the document several times (originally from draft-tschofenig-ecrit-security-threats-00.txt, draft-tschofenig-ecrit-security-threats-01.txt, draft-taylor-ecrit-security-threats-00.txt, draft-taylor-ecrit-security-threats-01.txt, draft-taylor-ecrit-security-threats-02.txt to the most recent version draft-taylor-ecrit-security-threats-03.txt). Please speak for or against making draft-taylor-ecrit-security-threats-03.txt a working group item for the ECRIT working group. Deadline for responding to this hum is the 17th March 2006. Ciao Hannes & Marc _______________________________________________ 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 Mon Mar 13 13:00:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrLa-00040s-8p; Mon, 13 Mar 2006 13:00:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrLY-00040j-Nl for ecrit@ietf.org; Mon, 13 Mar 2006 13:00:44 -0500 Received: from hme1.july.broomfield1.level3.net ([209.245.18.8] helo=f4bb49-05.idc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrLX-0007EE-CN for ecrit@ietf.org; Mon, 13 Mar 2006 13:00:44 -0500 Received: from machine77.Level3.com (qfe0.f10212-07.adc1.oss.level3.com [10.2.1.102]) by f4bb49-05.idc1.level3.com (8.12.10/8.12.10) with ESMTP id k2DI0eaK013988 for ; Mon, 13 Mar 2006 18:00:40 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id EFF3A12484D for ; Mon, 13 Mar 2006 18:00:39 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner5.level3.com (Postfix) with SMTP id B2A59124844 for ; Mon, 13 Mar 2006 18:00:39 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.9.15]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 11:00:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 13 Mar 2006 11:00:38 -0700 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC0037473F0@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LoST comment: Client request for region data Thread-Index: AcZGyAlH5eDkYBKhTo6Xo6hTt3Uhpw== From: "Hearty, John" To: X-OriginalArrivalTime: 13 Mar 2006 18:00:39.0472 (UTC) FILETIME=[0993C300:01C646C8] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Subject: [Ecrit] LoST comment: Client request for region data 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="===============1450551876==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1450551876== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C646C8.094529D0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C646C8.094529D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3 says: =20 Depending on the query, the result may contain a region where the same mapping would apply... The combination of these components are left to the needs and policy of the jurisdiction where the server is being operated. =20 It might be a good idea for the client to ask for the region in its query rather than (or in addition to) leaving it up to jurisdiction policy. For example, nomadic devices might be very interested in region information per point 2 that follows the above text. However, non-nomadic devices may not care about region information. =20 John Hearty Level3 Communications =20 ------_=_NextPart_001_01C646C8.094529D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3 says:

 

Depending on the = query, the result may contain a region where the same mapping would apply...  = The combination of these components are left to the needs and policy of the jurisdiction where the server is being operated.

 

It might be a good idea for the client to ask for the = region in its query rather than (or in addition to) leaving it up to = jurisdiction policy.  For example, nomadic devices might be very interested in = region information per point 2 that follows the above text.  However, = non-nomadic devices may not care about region information.

 

John Hearty

Level3 Communications

 

------_=_NextPart_001_01C646C8.094529D0-- --===============1450551876== 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 --===============1450551876==-- From ecrit-bounces@ietf.org Mon Mar 13 13:31:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrpC-00079Z-7E; Mon, 13 Mar 2006 13:31:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIrp9-00074P-Jk for ecrit@ietf.org; Mon, 13 Mar 2006 13:31:19 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIrp8-0008Tm-Ag for ecrit@ietf.org; Mon, 13 Mar 2006 13:31:19 -0500 Received: from lion.cs.columbia.edu (IDENT:qg3wd18BIuCtO5BKiSswqby4/1T6uhMe@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2DIVEOa020812 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 13 Mar 2006 13:31:18 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k2DIVEjN030001 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Mar 2006 13:31:14 -0500 Message-ID: <4415BA6D.1050505@cs.columbia.edu> Date: Mon, 13 Mar 2006 13:31:09 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Hearty, John" Subject: Re: [Ecrit] LoST comment: Client request for region data References: <3F75233A2E57CC468B35F3B1FAF71EC0037473F0@idc1exc0004.corp.global.level3.com> In-Reply-To: <3F75233A2E57CC468B35F3B1FAF71EC0037473F0@idc1exc0004.corp.global.level3.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: ecrit-bounces@ietf.org John, that's probably a good idea, but I'm in general concerned about complexity. The more options, the more code complexity and the more options to test. Besides a few extra bytes, there's no harm in transmitting the information. Non-nomadic devices are likely to provide civic address information; region information for this is likely to be as short as a partial PIDF civic address description, such as a town name or street address. In all likelihood, we'd be talking about fewer than 100 extra bytes here. I'd imagine that for most non-nomadic devices, getting a 100 bytes extra per day isn't going to make all that much difference. Henning Hearty, John wrote: > Section 3 says: > > > > Depending on the query, the result may contain a region where the same > mapping would apply... The combination of these components are left to > the needs and policy of the jurisdiction where the server is being operated. > > > > It might be a good idea for the client to ask for the region in its > query rather than (or in addition to) leaving it up to jurisdiction > policy. For example, nomadic devices might be very interested in region > information per point 2 that follows the above text. However, > non-nomadic devices may not care about region information. > > > > John Hearty > > Level3 Communications > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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 Mon Mar 13 14:03:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsJj-000295-Os; Mon, 13 Mar 2006 14:02:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsJi-000290-W5 for ecrit@ietf.org; Mon, 13 Mar 2006 14:02:54 -0500 Received: from qfe1.f10207-20.atlanta2.level3.net ([67.72.93.25] helo=f10207-20.adc1.level3.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIsJh-00010A-NO for ecrit@ietf.org; Mon, 13 Mar 2006 14:02:54 -0500 Received: from machine77.Level3.com (qfe0.f4ff49-08.idc1.oss.level3.com [10.1.156.103]) by f10207-20.adc1.level3.com (8.12.10/8.12.10) with ESMTP id k2DJ1x6r020316; Mon, 13 Mar 2006 19:02:19 GMT Received: from machine77.Level3.com (localhost [127.0.0.1]) by localhost.level3.com (Postfix) with ESMTP id 873CF78B577; Mon, 13 Mar 2006 19:01:48 +0000 (GMT) Received: from idc1exc0001.corp.global.level3.com (idc1exc0001.corp.global.level3.com [10.1.9.12]) by scanner3.l3.com (Postfix) with SMTP id 510B478B572; Mon, 13 Mar 2006 19:01:48 +0000 (GMT) Received: from idc1exc0004.corp.global.level3.com ([10.1.9.15]) by idc1exc0001.corp.global.level3.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 13 Mar 2006 12:01:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 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] LoST comment: Client request for region data Date: Mon, 13 Mar 2006 12:01:45 -0700 Message-ID: <3F75233A2E57CC468B35F3B1FAF71EC0037473F2@idc1exc0004.corp.global.level3.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] LoST comment: Client request for region data Thread-Index: AcZGzFVpLO/RA5zTRBmJvjHVT/pjzAAAfWeQ From: "Hearty, John" To: "Henning Schulzrinne" X-OriginalArrivalTime: 13 Mar 2006 19:01:48.0106 (UTC) FILETIME=[9440E2A0:01C646D0] X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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: , Errors-To: ecrit-bounces@ietf.org Good point. What if the jurisdiction policy is to not include the region? Then nomadic devices can't count on data when they move, and would either have to 1) send new queries each time they attach to a new AP, or 2) rely on a query when an emergency call is made. Option 1 might put undue load on the location servers. I believe there has been discussion on this list that option 2 may be bad. If including the region in responses was made mandatory these issues would go away. It also addresses your very valid concern by reducing complexity of what might be included in a response based on jurisdiction policy. John > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Monday, March 13, 2006 11:31 AM > To: Hearty, John > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] LoST comment: Client request for region data >=20 > John, >=20 > that's probably a good idea, but I'm in general concerned about > complexity. The more options, the more code complexity and the more > options to test. Besides a few extra bytes, there's no harm in > transmitting the information. Non-nomadic devices are likely to provide > civic address information; region information for this is likely to be > as short as a partial PIDF civic address description, such as a town > name or street address. In all likelihood, we'd be talking about fewer > than 100 extra bytes here. I'd imagine that for most non-nomadic > devices, getting a 100 bytes extra per day isn't going to make all that > much difference. >=20 > Henning >=20 > Hearty, John wrote: > > Section 3 says: > > > > > > > > Depending on the query, the result may contain a region where the same > > mapping would apply... The combination of these components are left to > > the needs and policy of the jurisdiction where the server is being > operated. > > > > > > > > It might be a good idea for the client to ask for the region in its > > query rather than (or in addition to) leaving it up to jurisdiction > > policy. For example, nomadic devices might be very interested in region > > information per point 2 that follows the above text. However, > > non-nomadic devices may not care about region information. > > > > > > > > John Hearty > > > > Level3 Communications > > > > > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > 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 Mon Mar 13 14:13:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsTo-0000VJ-MP; Mon, 13 Mar 2006 14:13:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FIsTn-0000VE-9o for ecrit@ietf.org; Mon, 13 Mar 2006 14:13:19 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FIsTn-0001LI-0n for ecrit@ietf.org; Mon, 13 Mar 2006 14:13:19 -0500 Received: from lion.cs.columbia.edu (IDENT:ec6x4I7LE4d0LdOfEv0oSNRgW1JFH0vG@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2DJDGOa005654 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Mon, 13 Mar 2006 14:13:16 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k2DJDGjN032545 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 13 Mar 2006 14:13:16 -0500 Message-ID: <4415C446.40109@cs.columbia.edu> Date: Mon, 13 Mar 2006 14:13:10 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Hearty, John" Subject: Re: [Ecrit] LoST comment: Client request for region data References: <3F75233A2E57CC468B35F3B1FAF71EC0037473F2@idc1exc0004.corp.global.level3.com> In-Reply-To: <3F75233A2E57CC468B35F3B1FAF71EC0037473F2@idc1exc0004.corp.global.level3.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, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Errors-To: ecrit-bounces@ietf.org I generally agree with your sentiment. In my opinion, having SHOULDs and "policy" in protocol specs are generally recipes for interoperability problems and excuses for implementor/contractor/supplier laziness. They are sometimes necessary, but MUST be used sparingly. It sounds harmless to say "local policy", but we should be very careful that we don't sound neutral on something we believe to be generally a bad idea. Not all operators fully understand the consequences of low-level design decisions, particularly if they buy off-the-shelf software. In this case, I believe the right answer is 'MUST implement' and 'MUST use for geo' (since the UA has no idea when to requery otherwise and can only guess wrong) and possibly a 'MAY use for civic' (since the use of regions is likely to be of less value for devices that query in civic, i.e., hot spots and landline). Clearly, you don't have to provide the exact boundary of your jurisdiction, as an approximation will do in some cases. Henning Hearty, John wrote: > Good point. What if the jurisdiction policy is to not include the > region? Then nomadic devices can't count on data when they move, and > would either have to 1) send new queries each time they attach to a new > AP, or 2) rely on a query when an emergency call is made. Option 1 > might put undue load on the location servers. I believe there has been > discussion on this list that option 2 may be bad. > > If including the region in responses was made mandatory these issues > would go away. It also addresses your very valid concern by reducing > complexity of what might be included in a response based on jurisdiction > policy. > > John > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >> Sent: Monday, March 13, 2006 11:31 AM >> To: Hearty, John >> Cc: ecrit@ietf.org >> Subject: Re: [Ecrit] LoST comment: Client request for region data >> >> John, >> >> that's probably a good idea, but I'm in general concerned about >> complexity. The more options, the more code complexity and the more >> options to test. Besides a few extra bytes, there's no harm in >> transmitting the information. Non-nomadic devices are likely to > provide >> civic address information; region information for this is likely to be >> as short as a partial PIDF civic address description, such as a town >> name or street address. In all likelihood, we'd be talking about fewer >> than 100 extra bytes here. I'd imagine that for most non-nomadic >> devices, getting a 100 bytes extra per day isn't going to make all > that >> much difference. >> >> Henning >> >> Hearty, John wrote: >>> Section 3 says: >>> >>> >>> >>> Depending on the query, the result may contain a region where the > same >>> mapping would apply... The combination of these components are left > to >>> the needs and policy of the jurisdiction where the server is being >> operated. >>> >>> >>> It might be a good idea for the client to ask for the region in its >>> query rather than (or in addition to) leaving it up to jurisdiction >>> policy. For example, nomadic devices might be very interested in > region >>> information per point 2 that follows the above text. However, >>> non-nomadic devices may not care about region information. >>> >>> >>> >>> John Hearty >>> >>> Level3 Communications >>> >>> >>> >>> >>> > ------------------------------------------------------------------------ >>> _______________________________________________ >>> 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 Wed Mar 15 03:41:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRZd-0007qT-9q; Wed, 15 Mar 2006 03:41:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJRZb-0007qO-TE for ecrit@ietf.org; Wed, 15 Mar 2006 03:41:39 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FJRZX-0000PF-ES for ecrit@ietf.org; Wed, 15 Mar 2006 03:41:39 -0500 Received: (qmail invoked by alias); 15 Mar 2006 08:41:34 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp034) with SMTP; 15 Mar 2006 09:41:34 +0100 X-Authenticated: #29516787 Message-ID: <4417D33E.5080101@gmx.net> Date: Wed, 15 Mar 2006 09:41:34 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org, Marc Linser Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [Ecrit] FW: Jabber service for IETF meetings 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: , Errors-To: ecrit-bounces@ietf.org Hi all, if anyone is planning on participating remotely, please let us know. Ciao Hannes >-----Original Message----- >From: ext IETF Secretariat [mailto:ietf-secretariat@ietf.org] >Sent: 15 March, 2006 06:26 >To: Working Group Chairs >Subject: Jabber service for IETF meetings > >Dear IETF WG Chairs, > >The Secretariat is pleased to announce a new Instant Messaging >service. This service will provide jabber chat rooms to all >IETF working groups for their text conferencing at IETF 65 and >future meetings. > >The new jabber server is located at jabber.ietf.org and is >currently accessible. For those who are interested, please >visit the above location to join any of the available chat rooms. > >Over the next few days, please take the time to test this new >service and provide us with all questions, comments, and >suggestions. Your feedback is key to our success! > >Please note: > >All traffic within the defined rooms (except "noc") is being >logged and updated every 5 minutes to the ietf.org website. > >To view the log directories, point your browser to >http://www.ietf.org/meetings/ietf-logs/. > >If you click on a room directory, you will see one or more >files named "YYYY-MM-DD.html", e.g. 2006-03-14.html. If you >click on one of those files, you will see all logged traffic >for that day. > >Please visit the IETF Text Conferencing Web page >(http://www.ietf.org/meetings/text_conf.html) for more information. > >The IETF Secretariat. > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 15 20:13:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJh3I-0008N6-NC; Wed, 15 Mar 2006 20:13:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJh3H-0008Mx-Tc for ecrit@ietf.org; Wed, 15 Mar 2006 20:13:19 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJh3G-0007Gm-LD for ecrit@ietf.org; Wed, 15 Mar 2006 20:13:19 -0500 Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 15 Mar 2006 20:12:27 -0500 id 0158810F.4418BB7B.0000781F In-Reply-To: <441192E4.8010209@gmx.net> References: <441192E4.8010209@gmx.net> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: <1B1353B4-0669-481A-BDE1-5662CF65018E@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Date: Wed, 15 Mar 2006 20:13:16 -0500 To: Hannes Tschofenig X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Content-Type: multipart/mixed; boundary="===============1959099836==" Errors-To: ecrit-bounces@ietf.org --===============1959099836== Content-Type: multipart/alternative; boundary=Apple-Mail-6-955639443 --Apple-Mail-6-955639443 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 10, 2006, at 9:53 AM, Hannes Tschofenig wrote: > Please speak for or against making > draft-taylor-ecrit-security-threats-03.txt a working group item for > the > ECRIT working group. I think Tom has done an excellent job with this draft and am in favor of it being a working group item. -andy --Apple-Mail-6-955639443 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=US-ASCII
On Mar 10, 2006, at 9:53 AM, Hannes Tschofenig wrote:

Please speak for or against making

draft-taylor-ecrit-security-threats-03.txt a working group item for the

ECRIT working group.


I think Tom has done an excellent job with this draft and am in favor of it being a working group item.

-andy
--Apple-Mail-6-955639443-- --===============1959099836== 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 --===============1959099836==-- From ecrit-bounces@ietf.org Wed Mar 15 20:30:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhJs-0002ii-Ot; Wed, 15 Mar 2006 20:30:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhJr-0002hz-5G for ecrit@ietf.org; Wed, 15 Mar 2006 20:30:27 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJhJq-0007T1-Tl for ecrit@ietf.org; Wed, 15 Mar 2006 20:30:27 -0500 Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 15 Mar 2006 20:29:36 -0500 id 0158810F.4418BF80.00007AE7 In-Reply-To: <4415C446.40109@cs.columbia.edu> References: <3F75233A2E57CC468B35F3B1FAF71EC0037473F2@idc1exc0004.corp.global.level3.com> <4415C446.40109@cs.columbia.edu> Mime-Version: 1.0 Message-Id: <2E4BDE1E-C146-4DF0-B18A-B800F59C05FC@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] LoST comment: Client request for region data Date: Wed, 15 Mar 2006 20:30:24 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.6 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: "Hearty, John" , 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: , Content-Type: multipart/mixed; boundary="===============0583846533==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0583846533== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-31466-1142472576-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-31466-1142472576-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 13, 2006, at 2:13 PM, Henning Schulzrinne wrote: > I generally agree with your sentiment. In my opinion, having > SHOULDs and "policy" in protocol specs are generally recipes for > interoperability problems and excuses for implementor/contractor/ > supplier laziness. They are sometimes necessary, but MUST be used > sparingly. Having clients depend on expectations that some server operators will not be able to meet due to policy reasons is an even bigger recipe for disaster. Just because we may not agree with such policies doesn't mean that some jurisdictions and some server operators will not have to abide by them. So servers SHOULD send the region data (in the true sense that SHOULD means if you do not you ought to know the consequences) and clients MUST be prepared to accept responses without region data. The last thing we want is a server pushing crap data across an inflexible protocol. With regard to complexity over a "I don't care for region data" flag, I think we have seriously bungled the problem from the start if such a simple thing adds just enough more complexity to make this thing hopeless. It's a boolean flag that short circuits a possibly complex lookup and bigger payload. Vendors who find it too complex ought not be distributing software. -andy --=_zeke.ecotroph.net-31466-1142472576-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.0
On Mar 13, 2006, at 2:1= 3 PM, Henning Schulzrinne wrote:

I= generally agree with your sentiment. In my opinion, having SHOULDs and "= policy" in protocol specs are generally recipes for interoperability prob= lems and excuses for implementor/contractor/supplier laziness. They are s= ometimes necessary, but MUST be used sparingly.

<= /DIV>
Having clients depend on expectations that some server oper= ators will not be able to meet due to policy reasons is an even bigger re= cipe for disaster.=A0 Just because we may not agree with such policies do= esn't mean that some jurisdictions and some server operators will not hav= e to abide by them.=A0 So servers SHOULD send the region data (in the tru= e sense that SHOULD means if you do not you ought to know the consequence= s) and clients MUST be prepared to accept responses without region data.=A0= The last thing we want is a server pushing crap data across an inflexibl= e protocol.

Wi= th regard to complexity over a "I don't care for region data" flag, I thi= nk we have seriously bungled the problem from the start if such a simple = thing adds just enough more complexity to make this thing hopeless.=A0 It= 's a boolean flag that short circuits a possibly complex lookup and bigge= r payload.=A0 Vendors who find it too complex ought not be distributing s= oftware.

-andy=
--=_zeke.ecotroph.net-31466-1142472576-0001-2-- --===============0583846533== 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 --===============0583846533==-- From ecrit-bounces@ietf.org Wed Mar 15 20:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhYz-0004O5-GX; Wed, 15 Mar 2006 20:46:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJhYy-0004O0-8q for ecrit@ietf.org; Wed, 15 Mar 2006 20:46:04 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJhYy-0007eO-2F for ecrit@ietf.org; Wed, 15 Mar 2006 20:46:04 -0500 Received: from [10.0.1.104] ([::ffff:64.83.8.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 15 Mar 2006 20:45:13 -0500 id 01588112.4418C329.00007D7B In-Reply-To: References: Mime-Version: 1.0 Message-Id: <83368C77-A15E-4D4E-9136-6DF22A084C7C@hxr.us> From: Andrew Newton Subject: Re: AW: [Ecrit] Review of draft-taylor-ecrit-security-threats-02.txt Date: Wed, 15 Mar 2006 20:46:01 -0500 To: "Tschofenig, Hannes" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Content-Type: multipart/mixed; boundary="===============0047794051==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0047794051== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-32127-1142473513-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-32127-1142473513-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 1, 2006, at 5:19 AM, Tschofenig, Hannes wrote: > here, i again think that it is not a problem. TLS performance tests > have shown that it is not really a problem. I believe if you have long lived sessions where TLS is using symmetric cryptography that this may be the case, but for a short lived sessions in a request/response protocol TLS will certainly add to performance issues. The simple test I presented at the interim showed a 3.4 times greater latency with TLS than over plain TCP. > what could cause problems is certificate validation, path > validation, CRL checking, etc.. this is, however, a separate issue > that we tried to soften with the "SHOULD" regarding usage. Certainly there seems no point to invoking heavy weight public key cryptography if the results are to just be thrown away. -andy --=_zeke.ecotroph.net-32127-1142473513-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.0
On Mar 1, 2006, at 5:19= AM, Tschofenig, Hannes wrote:

her= e, i again think that it is not a problem. TLS performance tests have sho= wn that it is not really a problem.


I believe if you have long l= ived sessions where TLS is using symmetric cryptography that this may be = the case, but for a short lived sessions in a request/response protocol T= LS will certainly add to performance issues.=A0 The simple test I present= ed at the interim showed a 3.4 times greater latency with TLS than over p= lain TCP.

what could cause problems is certificate validation, path va= lidation, CRL checking, etc.. this is, however, a separate issue that we = tried to soften with the "SHOULD" regarding usage.


Certainly there seems no point to invoking heavy weight = public key cryptography if the results are to just be thrown away.
<= DIV>
-andy
--=_zeke.ecotroph.net-32127-1142473513-0001-2-- --===============0047794051== 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 --===============0047794051==-- From ecrit-bounces@ietf.org Thu Mar 16 07:59:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJs4e-00038K-6p; Thu, 16 Mar 2006 07:59:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJs4d-00038F-19 for ecrit@ietf.org; Thu, 16 Mar 2006 07:59:27 -0500 Received: from rwcrmhc12.comcast.net ([216.148.227.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJs4c-0000Oz-P4 for ecrit@ietf.org; Thu, 16 Mar 2006 07:59:27 -0500 Received: from s73602 (c-24-1-104-165.hsd1.tx.comcast.net[24.1.104.165]) by comcast.net (rwcrmhc12) with SMTP id <20060316125925m1200je1mle>; Thu, 16 Mar 2006 12:59:26 +0000 Message-ID: <0ec801c648f9$242f3d10$0500a8c0@china.huawei.com> From: "Spencer Dawkins" To: References: <441192E4.8010209@gmx.net> Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Date: Thu, 16 Mar 2006 06:57:11 -0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: , Errors-To: ecrit-bounces@ietf.org I reviewed this draft and think it's very reasonable to make it a WG draft. Thanks, Spencer > Hi all, > > we have a charter item for an informational document describing the > threats and security considerations. > > Tom has resently submitted another draft update that matches this charter > item: > http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-03.txt > > This document is the outcome of many discussions and the desire to change > the content and scope of the document several times (originally from > draft-tschofenig-ecrit-security-threats-00.txt, > draft-tschofenig-ecrit-security-threats-01.txt, > draft-taylor-ecrit-security-threats-00.txt, > draft-taylor-ecrit-security-threats-01.txt, > draft-taylor-ecrit-security-threats-02.txt to the most recent version > draft-taylor-ecrit-security-threats-03.txt). > > Please speak for or against making > draft-taylor-ecrit-security-threats-03.txt a working group item for the > ECRIT working group. > > Deadline for responding to this hum is the 17th March 2006. > > Ciao > Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 16 08:32:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsaN-0007xJ-E9; Thu, 16 Mar 2006 08:32:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJsaL-0007uA-Nq for ecrit@ietf.org; Thu, 16 Mar 2006 08:32:13 -0500 Received: from arachne.bofh.priv.at ([193.154.150.108] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJsaK-0001cM-Eb for ecrit@ietf.org; Thu, 16 Mar 2006 08:32:13 -0500 Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 687681A3C2; Thu, 16 Mar 2006 14:32:11 +0100 (CET) Date: Thu, 16 Mar 2006 14:32:11 +0100 From: Otmar Lendl To: ecrit@ietf.org Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping" Message-ID: <20060316133211.GA16744@nic.at> References: <8C837214C95C864C9F34F3635C2A65750470658B@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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: , Errors-To: ecrit-bounces@ietf.org On 2006/03/11 17:03, Henning Schulzrinne wrote: > Here's my hum: > > http://amasci.com/hum/avebury5.wav > My hum is strictly ASCII, and adds to the chorus for the acceptance as ECRIT working group item. /ol -- < Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 16 12:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJw6I-0008TP-EY; Thu, 16 Mar 2006 12:17:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FJw6H-0008TK-1Z for ecrit@ietf.org; Thu, 16 Mar 2006 12:17:25 -0500 Received: from mclmx.mail.saic.com ([149.8.64.10]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FJw6F-0001ND-Ps for ecrit@ietf.org; Thu, 16 Mar 2006 12:17:25 -0500 Received: from 0015-its-ieg02.mail.saic.com ([149.8.64.21] [149.8.64.21]) by mclmx.mail.saic.com; Thu, 16 Mar 2006 12:16:57 -0500 Received: from mcl-its-exig01.mail.saic.com ([149.8.64.12]) by 0015-its-ieg02.mail.saic.com (SMSSMTP 4.0.5.66) with SMTP id M2006031612165714125 ; Thu, 16 Mar 2006 12:16:57 -0500 Received: by mcl-its-exig01.mail.saic.com with Internet Mail Service (5.5.2657.72) id ; Thu, 16 Mar 2006 12:16:57 -0500 Message-Id: From: "Roy, Radhika R." To: Spencer Dawkins , ecrit@ietf.org Subject: RE: [Ecrit] Hum for "Security Threats and Requirements for Emerge ncyCall Marking and Mapping" Date: Thu, 16 Mar 2006 12:16:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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: , Errors-To: ecrit-bounces@ietf.org Hi, all: I would request to kind use the "Voice/Real-Time-Text" instead of "Voice" in the document. For example, Section 2 (2nd Para) uses ".... Application (Voice) ..." has been used. Please replace this as follows: ".... Application (Voice/Real-Time-Text) ..." Best regards, Radhika _____ From: ecrit-bounces@ietf.org on behalf of Spencer Dawkins Sent: Thu 3/16/2006 7:57 AM To: ecrit@ietf.org Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for EmergencyCall Marking and Mapping" I reviewed this draft and think it's very reasonable to make it a WG draft. Thanks, Spencer > Hi all, > > we have a charter item for an informational document describing the > threats and security considerations. > > Tom has resently submitted another draft update that matches this charter > item: > http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-03.t xt > > This document is the outcome of many discussions and the desire to change > the content and scope of the document several times (originally from > draft-tschofenig-ecrit-security-threats-00.txt, > draft-tschofenig-ecrit-security-threats-01.txt, > draft-taylor-ecrit-security-threats-00.txt, > draft-taylor-ecrit-security-threats-01.txt, > draft-taylor-ecrit-security-threats-02.txt to the most recent version > draft-taylor-ecrit-security-threats-03.txt). > > Please speak for or against making > draft-taylor-ecrit-security-threats-03.txt a working group item for the > ECRIT working group. > > Deadline for responding to this hum is the 17th March 2006. > > Ciao > Hannes & Marc _______________________________________________ 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 Mar 16 17:54:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1Mb-0000R0-GS; Thu, 16 Mar 2006 17:54:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FK1Ma-0000Or-GT for ecrit@ietf.org; Thu, 16 Mar 2006 17:54:36 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FK1Ma-0004l6-7N for ecrit@ietf.org; Thu, 16 Mar 2006 17:54:36 -0500 Received: from sjcc176x230.sjccnet.com ([216.1.176.230] helo=[10.75.100.232]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FK1MY-0003rR-Lq; Thu, 16 Mar 2006 16:54:34 -0600 Message-ID: <4419ECA9.6040100@ntt-at.com> Date: Thu, 16 Mar 2006 14:54:33 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ecrit@ietf.org Subject: Re: [Fwd: Re: [Ecrit] Hum for "Security Threats and Requirements for Emergency Call Marking and Mapping"] References: <4411F9FC.8030303@gmx.net> In-Reply-To: <4411F9FC.8030303@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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: , Errors-To: ecrit-bounces@ietf.org Large hum to adopt this as a WG item. This might had been discussed but, after glancing through the draft, it occurred to me that with the emergency marking defined with the new Service-URN draft, malicious UA can send INVITE with Accept-Contact header value of "service:urn:sos" and anticipate a priority treatment of the call as if it was an emergency call. Before as I understand the call was understood to be emergency call when request-URI was a URI of emergency URI(sos@domain.com or service:urn) which at the same time was used as a marking for an emergency call. This property also enforced the whole mapping procedure to take place which at the same time prevented call being made to non-psap entity with emergency marking. But because this URI is translated after the mapping to PSAP uri which is unidentifiable as an emergency URI, it was agreed to add a marking so entity receiving the emergency call after the mapping(which has no emergency URI) can identity the call as an emergency call. But this new marking method allows malicious user to set this value and have the call seen as an emergency call. Also if you have the emergency URI in To: and Request URI would you still need the marking? To:'s URI will stay as an emergency URI until it reaches the PSAP right? BTW using To as an emergency identifier does not solve the problem either unless mapping is enforced every time, and redirecting the psap uri to UAC is not allowed(Which disallow direct emergency mapping from UAC). Dilemma of resource-priority header revisited, actually with resource-priority the call is treated differently only if the server understands the resource-priority value but this is a generic value which we anticipate all servers to understand.. ..Scary.. Regards Shida Schubert Hannes Tschofenig wrote: > > Do you guys also have an opinion about this draft? > It might be good to hear your thoughts. > > > -------- Original Message -------- > Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for > Emergency Call Marking and Mapping" > Date: Fri, 10 Mar 2006 13:58:17 -0800 > From: Ted Hardie > To: Hannes Tschofenig , ecrit@ietf.org, > Marc Linser > References: > > <441192E4.8010209@gmx.net> > > At 3:53 PM +0100 3/10/06, Hannes Tschofenig wrote: >> >> Please speak for or against making >> draft-taylor-ecrit-security-threats-03.txt a working group item for the >> ECRIT working group. >> >> Deadline for responding to this hum is the 17th March 2006. >> > > I believe it is appropriate for this to be working group item. > > Ted Hardie > > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 19 13:54:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL338-000392-WA; Sun, 19 Mar 2006 13:54:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL337-00038x-PW for ecrit@ietf.org; Sun, 19 Mar 2006 13:54:45 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FL336-0005GA-Fo for ecrit@ietf.org; Sun, 19 Mar 2006 13:54:45 -0500 Received: (qmail invoked by alias); 19 Mar 2006 18:54:42 -0000 Received: from dhcp64-134-222-98.ssmc.dal.wayport.net (EHLO [64.134.222.98]) [64.134.222.98] by mail.gmx.net (mp001) with SMTP; 19 Mar 2006 19:54:42 +0100 X-Authenticated: #29516787 Message-ID: <441DA8F5.4060302@gmx.net> Date: Sun, 19 Mar 2006 19:54:45 +0100 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org, Marc Linser Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: Subject: [Ecrit] Presentations for Upload 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: , Errors-To: ecrit-bounces@ietf.org Hi all, please send us your presentations to upload them to https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 19 17:26:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6MN-00012t-TW; Sun, 19 Mar 2006 17:26:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6MN-00012n-02 for ecrit@ietf.org; Sun, 19 Mar 2006 17:26:51 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6ML-0005oQ-MJ for ecrit@ietf.org; Sun, 19 Mar 2006 17:26:50 -0500 Received: from [130.129.134.205] (helo=[130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FL6MJ-00065t-OW; Sun, 19 Mar 2006 16:26:48 -0600 Message-ID: <441DDAA6.6080604@ntt-at.com> Date: Sun, 19 Mar 2006 14:26:46 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] draft-ietf-ecrit-service-urn-01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: ecrit-bounces@ietf.org Hi Henning; As I noted in another e-mail. If the service-urn in Accept-Contact header is to be used as a marking for emergency call. I think some security consideration for handling the call when the marking exists should be noted. Regards Shida Schubert Henning Schulzrinne wrote: > I have submitted an update to the service URN draft; you can find the > HTML version at > > http://www.cs.columbia.edu/sip/draft/service/draft-ietf-ecrit-service-urn-01.html > > > I believe it incorporates the comments received so far. Major changes > include: > > - registration of services > > - description of service feature tag > > - security considerations > > - description of alternatives considered, as an appendix > > - DDDS description > > I now consider the document complete; there are no open issues listed. > However, I'd like feedback on the DDDS description, as it makes > certain choices. In particular, it assumes that various configuration > protocols, such as DHCP and SIP configuration, will provide a domain > name that provides a NAPTR record. The advantage of this approach is > that a DHCP response doesn't have to include a long list of service > mapping protocols, with preferences and other data, particularly if > different services are hosted at different servers. > > There would likely be a separate definition for an ENUM service for > the mapping protocol, but that doesn't quite fit into the scope of > this draft and warrants a separate document. > > My suggestion would be to last-call the document after the IETF > meeting, giving an opportunity for discussion at the ECRIT meeting. In > order to better prepare for the meeting discussion, I'd appreciate if > folks could read the document. It's short... > > Henning > > _______________________________________________ > 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 Sun Mar 19 17:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6Vn-0007PR-5h; Sun, 19 Mar 2006 17:36:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FL6Vm-0007PM-6C for ecrit@ietf.org; Sun, 19 Mar 2006 17:36:34 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FL6Vk-00062z-VD for ecrit@ietf.org; Sun, 19 Mar 2006 17:36:34 -0500 Received: from [192.168.0.41] (pool-141-153-201-146.mad.east.verizon.net [141.153.201.146]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.0/8.13.0) with ESMTP id k2JMaIaV026531 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 19 Mar 2006 17:36:19 -0500 (EST) In-Reply-To: <441DDAA6.6080604@ntt-at.com> References: <441DDAA6.6080604@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <26659D71-5AAA-4510-AB25-7780993D3470@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] draft-ietf-ecrit-service-urn-01 Date: Sun, 19 Mar 2006 17:36:16 -0500 To: Shida Schubert X-Mailer: Apple Mail (2.746.3) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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: , Errors-To: ecrit-bounces@ietf.org This is one of the two major open issues I plan to discuss on Tuesday. (The other is the DDDS approach.) I suspect regardless of the marking, you'll always have the problem that a node that did not insert the marker, but wants to grant special privileges based on it, needs to either (1) ascertain that the marked was inserted by a trusted party OR (2) that the request URL actually points to a PSAP. The problem for (1) is somewhat similar to the P-Asserted-Id issue. It may well be that the outcome is similar, namely something akin to the SIP Identity header mechanism to allow a receiver to find out who signed for this. For (2), the main role of the header is then to alert the recipient to perform the verification. This sounds onerous, but unless PSAP URLs suddenly turn into the local Walmart, the proxy can easily cache this "yes, sip:sos@state.gov is a PSAP" information. Storing credentials in DNS (see another SIP draft) is also a possibility, but only if there's a globally recognized "this is a PSAP" signature. I'm using marker here generically, as I believe that the issues don't depend on whether this is a new header, a URL parameter or Accept- Contact. Henning On Mar 19, 2006, at 5:26 PM, Shida Schubert wrote: > > Hi Henning; > > As I noted in another e-mail. If the service-urn in Accept-Contact > header is > to be used as a marking for emergency call. I think some security > consideration for > handling the call when the marking exists should be noted. > > Regards > Shida Schubert _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 20 12:39:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOMD-0004he-Fs; Mon, 20 Mar 2006 12:39:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLOMB-0004go-Tg for ecrit@ietf.org; Mon, 20 Mar 2006 12:39:51 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLOMA-0003UK-Bg for ecrit@ietf.org; Mon, 20 Mar 2006 12:39:51 -0500 Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 20 Mar 2006 09:39:50 -0800 X-IronPort-AV: i="4.03,111,1141632000"; d="scan'208"; a="262917098:sNHT33678930" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k2KHdmYk013168 for ; Mon, 20 Mar 2006 09:39:49 -0800 (PST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 12:40:07 -0500 Received: from [130.129.128.208] ([10.82.208.105]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 12:39:48 -0500 Message-ID: <441EE8E6.1050104@cisco.com> Date: Mon, 20 Mar 2006 12:39:50 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 17:39:49.0051 (UTC) FILETIME=[4928E8B0:01C64C45] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [Ecrit] comments on service-urn 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: , Errors-To: ecrit-bounces@ietf.org > Since service URNs are not routable, a proxy or user agent has to > translate the service URN into a routable URL for a location- > appropriate service provider, such as a SIP URL. LoST [24] is one s/URL/URI > We discuss alternative approaches in Appendix A. For example, the > tel URI [20] allows to express service codes such as "911" for > emergency services by adding a context parameter, but does not > address the problem of global validity. this paragraph seems out of place to me; the text above and below talk about resolution mechanisms based on domain name and location respectively. This text is talking about alternative solutions to service-urn itself. I'd drop the paragraph entirely, since it almost seems to suggest that tel:911 is a valid solution as well. > For SIP, the service URN will likely appear in either the request URI > or the To header field, depending on which SIP element recognizes the > request as identifying an emergency call. If the mapping is done by > a proxy, the call may no longer be recognizable as an emergency call. We need to make sure there is an unambiguous way to recognize the call as 911. Its clear that it needs to be r-uri and not To because proxies WILL be doing this. The traditional problem we've had with r-uri is that it is rewritten by proxies for both retargeting (truly sending to a new destination user, as in call forwarding) and call routing (delivering the request to a registered contact for that user). I'll note that my proposal at last ietf of not translating the r-uri, but rather pushing Route headers, would solve this problem. > offer such mechanisms. The ECRIT working group is currently > discussing several approaches, including solutions based on DNS, > IRIS and a web-services protocol. Software prototypes for some of > these are currently already available and are believed to be > readily developed. this seems out of place for an IANA registration; which is permanent. > Identifier uniqueness considerations: A service URN identifies a > logical service, specified in the service registration (see IANA > considerations). Resolution of the URN, if successful, will > return a particular instance of the service, and this instance may > be different even for two users making the same request in the > same place at the same time; the logical service identified by the > URN, however, is persistent and unique. Right; I think the registration template is really aimed at discussing the last bit here. In particular, I think you need to say that service URN MUST be unique for each unique service, and that this is guaranteed through registration of each service within the service namespace. > Process of identifier assignment: Details of the service assignment > depend on the service and national regulations. In general, it is > assumed that providers of services can register through a service > mapping mechanism for a particular service in a particular > geographic area. The provision of some services may be restricted > by local or national regulations. (As a hypothetical example, > providing emergency services may be restricted to government- > authorized entities, which may limit the region where each entity > can advertise its services.) The rules for each service are > described in a service-specific document. true, but your text here is addressing how the service URN is mapped to a particular instance of the service (through LoST or NAPTR or whatever). I think the real issue is how new services themselves are registered. I had assumed this was through a standards track RFC which defines services, but that probably requires some discussion. > by the mapping protocols, an instance of a Resolution Discovery > System (RDS) as described in RFC 2276 [3]. There could be several > such mapping protocols in concurrent use, as long as there are > reasonable guarantees that all services are available in all > mapping protocols. Section 4 describes the DDDS service that uses > DNS NAPTR records to find an instance of a mapping service. I doubt this is true; I would think that some services will be available from some mapping protocols, others from different ones. For example, some services are inherently location based and would be available from location oriented resolution services like what ecrit is doing. Others are going to be domain specific and would only be from there. So, there is a real issue here about how you know which mapping services are available for a particular service URN. Maybe this is defined by the service URN registration itself? > For example, a user agent could request to be routed to marine rescue > by including the following SIP header field: > > Accept-Contact: *;sip.service="urn:service:sos.marine" This is not an unreasonable thing to do; the problem is that it buries an important identification (that this is an emergency call) deep within a header field used for many other purposes. So every proxy will need to inspect the accept-contact for this service value? I rather prefer request-URI as an in-your-face unambigous identifier. > 4.2 First Well Known Rule > > The first well known rule extracts a key from the AUS. For this > application, the first well known rule extracts the service portion > from the URN, i.e., the "service" part described in Declaration of > Syntactic Structure (Section 2). So, not the sub-service? > In summary, a client that wants to resolve a service URN obtains a > domain name through a variety of means, looks up the NAPTR record for > the resolution service and used the regular expression in that record > to transform the service URN into a protocol URL that leads to the > mapping service. Ah.. I had misunderstood the use case for the DDDS service. I thought the DDDS application was to actually get to the service URI, i.e.: urn:service.pizza at provider.com -> sip:dominoes-pizza@provider.com rather than getting the mapping service. If you are using DDDS to get the mapping service URL (a reasonable idea), then the issue about needing to have each service mappable through each mapping service goes away. > prevention hotline. > urn:service:sos.mental-health The 'mental-health' service refers to > the "[d]iagnostic, treatment, and preventive care that helps why is [d] in square brackets? > 5.2 SIP Media Feature Tag Registration: Service > > This specification defines an additional media feature tag, extending > the SIP tree entries described in [8] and following the registration > process in Section 12.1 of that document. This section serves as the > IANA registration for the service feature tags, which are made into > the SIP media feature tag tree. > > Media feature tag name: sip.service > ASN.1 Identifier: New assignment by IANA. If we go this way, you need to actually provide the ASN.1 identifier. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Mar 20 15:38:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLR8z-0007xJ-78; Mon, 20 Mar 2006 15:38:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLR8x-0007wd-C4 for ecrit@ietf.org; Mon, 20 Mar 2006 15:38:23 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLR8w-00028W-TV for ecrit@ietf.org; Mon, 20 Mar 2006 15:38:23 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k2KKW3A18317; Mon, 20 Mar 2006 15:32:03 -0500 (EST) Received: from [127.0.0.1] ([47.102.178.189] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 20 Mar 2006 15:36:23 -0500 Message-ID: <441F1248.5090604@nortel.com> Date: Mon, 20 Mar 2006 15:36:24 -0500 From: "Tom-PT Taylor" User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy, Radhika R." Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for Emerge ncyCall Marking and Mapping" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Mar 2006 20:36:23.0865 (UTC) FILETIME=[F4293A90:01C64C5D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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: , Errors-To: ecrit-bounces@ietf.org This change would have to be made in the requirements document. I just took the term from there. In fact, the medium of communication is really irrelevant in the security document as it stands. My proposed solution is therefore simply to remove the term "ASP/VSP". The resulting changes in the document (outside the terminology section) are as follows: Section 4, bullet: "to gain fraudulent use of ASP/VSP services,..." becomes "to gain fraudulent use of services,..." First sentence of 5.1: same. Section 5.1 bullet c) currently reads: "The call enters the domain of an ASP/VSP...". Change to: "The call enters the domain of a service provider...". Section 5.1 bullet d) currently reads: "The ASP/VSP routes it according to the called address...". Change to: "The service provider routes it according to the called address...". Roy, Radhika R. wrote: > Hi, all: > > I would request to kind use the "Voice/Real-Time-Text" instead of "Voice" in > the document. > > For example, Section 2 (2nd Para) uses ".... Application (Voice) ..." has > been used. Please replace this as follows: > > ".... Application (Voice/Real-Time-Text) ..." > > > > Best regards, > > Radhika > > > _____ > > From: ecrit-bounces@ietf.org on behalf of Spencer Dawkins > Sent: Thu 3/16/2006 7:57 AM > To: ecrit@ietf.org > Subject: Re: [Ecrit] Hum for "Security Threats and Requirements for > EmergencyCall Marking and Mapping" > > > > I reviewed this draft and think it's very reasonable to make it a WG draft. > > Thanks, > > Spencer > > > >>Hi all, >> >>we have a charter item for an informational document describing the >>threats and security considerations. >> >>Tom has resently submitted another draft update that matches this charter >>item: >> > > http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-03.t > xt > txt> > >>This document is the outcome of many discussions and the desire to change >>the content and scope of the document several times (originally from >>draft-tschofenig-ecrit-security-threats-00.txt, >>draft-tschofenig-ecrit-security-threats-01.txt, >>draft-taylor-ecrit-security-threats-00.txt, >>draft-taylor-ecrit-security-threats-01.txt, >>draft-taylor-ecrit-security-threats-02.txt to the most recent version >>draft-taylor-ecrit-security-threats-03.txt). >> >>Please speak for or against making >>draft-taylor-ecrit-security-threats-03.txt a working group item for the >>ECRIT working group. >> >>Deadline for responding to this hum is the 17th March 2006. >> >>Ciao >>Hannes & Marc > > > > > _______________________________________________ > 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 Mar 21 09:22:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhkD-0005eu-Uf; Tue, 21 Mar 2006 09:21:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLhkC-0005eg-0J for ecrit@ietf.org; Tue, 21 Mar 2006 09:21:56 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLhk9-0001K9-HP for ecrit@ietf.org; Tue, 21 Mar 2006 09:21:55 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Tue, 21 Mar 2006 06:21:52 -0800 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: RE: [Ecrit] [Comments on ECRIT Requirement] Date: Tue, 21 Mar 2006 06:21:41 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657504826B21@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] [Comments on ECRIT Requirement] Thread-Index: AcZBumZpZH0VpwmxSFSpDom9rV9Y6ALNDAug From: "Roger Marshall" To: "Shida Schubert" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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: , Errors-To: ecrit-bounces@ietf.org Shida: See my responses inline. =20 >-----Original Message----- >From: Shida Schubert [mailto:shida@ntt-at.com]=20 >Sent: Monday, March 06, 2006 11:26 PM >To: ecrit@ietf.org >Subject: [Ecrit] [Comments on ECRIT Requirement] > > >I haven't read the draft since version 02 and it definitely=20 >reads much better. Also I haven't compared my comments to what=20 >Roger recently posted as an upcoming changes, so I do=20 >apologize if I am repeating something here. > >Anyhow, here are my comments and questions. > >1. Wording seem to lack consistency in the following=20 >requirements although, I believe they meant to mean the same=20 >-> MUST implement(not necessarily use) > >Re 7. MUST implement(not necessarily use) Lo 1, Lo7. MUST=20 >implement Lo 2, Lo 3, Id2. MUST support(i.e required to=20 >implement though not required to use.) > >I think there was more, but I think it's better to be=20 >consistency with the wording. I think you're right. At least for the "MUST support (i.e., implement but not nec. use)" types, these could all be worded the same, I think. > >2. I found the following statement in Lo 3's to be rather unclear. > >"The protocol MUST support(i.e. must implement in the=20 >protocol, though not necessarily use) a mechanism to indicate=20 >that a location or a part of a location is known to not exist" > >It's not clear what is said by "location is known to not exist". >Is it trying to address the situation where address which is=20 >non-existent in the real world is in the request? or is it=20 >simply trying to address situation where the location in the=20 >request is non-existent in the location database that mapping=20 >entity references(Possibly due to new street being built but=20 >propagation has not been completed or simply the request is phony?). > >I think it's the latter that we are trying to address here,=20 >but may be the requirement is trying to address both cases. I'm not sure that it matters, whether the address is not yet, or (actually) exists, but is missing from a database. In either case, the location being referenced is problematic, and needs to be resolved. Does anyone else agree/disagree? > >3. Confusion in IdN >Is universal emergency identifier in Id1 and universal=20 >identifier in Id10 different? >If they are the same, two requirements seem to be stating the=20 >same thing. Yes, you're right. I will plan to remove Id9 (since renumbering, these are now Id1/Id9). > >4. What's the difference between emergency marking and=20 >emergency identifier? >Looking at the terminology, they seem to indicate the same=20 >thing. I guess this is what Tom was pointing out.. If the text=20 >from "translated.. " is removed from the terminology section,=20 >I don't think the confusion will occur, but may be Emergency=20 >identifier instead of marking should be used to be consistent=20 >with the terminology used. Change already made (ref. item 21. in my 3/06 email). > >5. I know that most likely candidate for the mapping protocol=20 >is SIP, but I thought that the mapping protocol is supposed to=20 >support other protocol as well. >If my >understanding is correct, it's odd to see SIP specific=20 >requirement seen in Id7 as well as Id12. It's really not a big=20 >deal, but they seemed out of place. > Point taken. Will plan to change wording from "(i.e., SIP UA)" to "(e.g., SIP UA)". >6. Id12 seems to cover Id7. Id12 was deleted as of -06. > >7. Ma5 and Ma7 both seem to say "MUST be able to return=20 >multiple PSAP URIs"? > I don't think the two requirements are saying the same thing at all. Additionally, Ma5 Motivation part has been deleted as of -06. >8. Re7 seems to cover Ma13 and may be Ma17. > Re7 relocated to mapping section. Ma13 has been deleted as of -06. Ma17 has been reworded in -06. >9. Ma24. "LCMS query" pops up only at this requirement. If we=20 >are to use this term here I think we should add "LCMS query"=20 >in terminology section. > Term, LCMS, has been deleted as of -06. Thanks for these comments. Roger Marshall >Regards >Shida Schubert > > > >_______________________________________________ >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 Mar 21 10:08:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiTY-0003bR-4E; Tue, 21 Mar 2006 10:08:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLiTW-0003aT-1P for ecrit@ietf.org; Tue, 21 Mar 2006 10:08:46 -0500 Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FLiTU-00032a-Ok for ecrit@ietf.org; Tue, 21 Mar 2006 10:08:46 -0500 Received: (qmail invoked by alias); 21 Mar 2006 15:08:43 -0000 Received: from DHCP-Wireless-129-200.ietf65.org (EHLO [130.129.129.200]) [130.129.129.200] by mail.gmx.net (mp034) with SMTP; 21 Mar 2006 16:08:43 +0100 X-Authenticated: #29516787 Message-ID: <442016FF.7020007@gmx.net> Date: Tue, 21 Mar 2006 09:08:47 -0600 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Ecrit] Slides 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: , Errors-To: ecrit-bounces@ietf.org Hi all, please find the slides at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=65 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 21 12:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkHm-0005ns-DJ; Tue, 21 Mar 2006 12:04:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLkHl-0005nj-Qr for ecrit@ietf.org; Tue, 21 Mar 2006 12:04:45 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLkHk-0008DA-JU for ecrit@ietf.org; Tue, 21 Mar 2006 12:04:45 -0500 Received: from dhcp-wireless-134-205.ietf65.org ([130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FLkHi-00078E-Sy for ecrit@ietf.org; Tue, 21 Mar 2006 11:04:42 -0600 Message-ID: <44203227.9050401@ntt-at.com> Date: Tue, 21 Mar 2006 09:04:39 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ecrit] Potential problem with re-mapping. 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: , Errors-To: ecrit-bounces@ietf.org Pondering over the solution of re-mapping, I realized that there are 2 cases(that I can think of) where resolution of mapping conducted by Outbound proxy may differ from what's inside the message, even if existing URI in the message is really a PSAP URI. 1. When there are several PSAPs managing the same region and LOST possibly returning URIs that are different sort of in a round robin fashion. 2. When LOST server responsible for the region is overloaded and mapping request is redirected to LOST server responsible for neighboring region, returning a PASP URI for the region, LOST server is responsible. Case 1 arose because of the current requirement allows for mutliple PSAP managing one region(Ma16) yet only allowing one PSAP URI per scheme. So every LOST request can return a different PSAP URI. I don't think Case 2 can be solved using re-mapping method. Something along the line of TLD solution or SIP-Cert may work. I might be misreading the requirement, so if I am I apologize. Regards Shida _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 21 15:35:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnZB-000631-E7; Tue, 21 Mar 2006 15:34:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLnZA-00062r-Hg for ecrit@ietf.org; Tue, 21 Mar 2006 15:34:56 -0500 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLnZ9-0007k0-9C for ecrit@ietf.org; Tue, 21 Mar 2006 15:34:56 -0500 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 14:34:54 -0600 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 21 Mar 2006 14:34:54 -0600 Received: from aopex5.andrew.com ([10.3.20.205]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Mar 2006 14:34:54 -0600 Message-ID: From: "Thomson, Martin" To: Date: Tue, 21 Mar 2006 14:34:53 -0600 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 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 21 Mar 2006 20:34:54.0129 (UTC) FILETIME=[E9165A10:01C64D26] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: On DDDS discovery Thread-Index: AcZNJuh3/8DpVz9vRruNHnIMWCNidg== X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Ecrit] On DDDS discovery 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: , Errors-To: ecrit-bounces@ietf.org In relation to my suggestion that S-NAPTR be used for discovery of LoST. =20 The main argument I heard against this was that it could delay the service = URN document, which is important and already running slightly late -- a fai= r comment. In light of the fact that the discovery section is now being mo= ved to the LoST draft, which is less constrained by time, I would like to r= e-float the argument. =20 S-NAPTR simplifies the deployment of NAPTR. For LoST, I don't see any need= for the extra features that are excluded from the S-NAPTR profile. S-NAPT= R would reduce the complexity of resolvers and the provisioning/data manage= ment effort at the DNS. A better argument for the use of S-NAPTR is in RFC= 3958 (Section 5). =20 A small update to RFC 3958, one that the authors agree would be (relatively= ) easy to acheive and quite desirable, is to add support for URI results (t= he "U" flag). =20 I do have a draft (available on request - it needs a rewrite) that includes= the both the change to S-NAPTR and additional information that can be used= to retrieve a service URI or a WSDL document that describes the service in= more detail. =20 The following example might apply to LoST: example.com. ;; order weight flags service regexp ;; replacement IN NAPTR 100 10 "U" "LOST:https" "" ( "https://ws.example.com/services/myws" ) IN NAPTR 200 10 "U" "LOST:http" "" ( "http://ws.example.com/services/myws" ) This example uses a set of newly defined S-NAPTR application protocol tags.= SOAP and BEEP was the other option. The result is the base URI for the s= ervice. The other option is to retrieve a WSDL document for the service that can in= clude additional information about the service: example.com. ;; order weight flags service regexp ;; replacement IN NAPTR 100 10 "U" "LOST:WSDL" "" ( "https://ws.example.com/wsdl/lost.wsdl" ) The only thing that this solution doesn't include is the way that the path = component of the URI is populated with the service tag ("sos", "sos.fire", = etc...). Personally, even though I understand some of the benefits of this= approach, I don't think that this is the place for that sort of informatio= n. That is information for request bodies and the LoST protocol. These pa= rameters can form part of the request URI using the above results as a base= URI, but if the URI contains protocol data, its format should be specified= in a protocol document, not DNS. Regards, Martin =20 =20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 21 16:54:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLooI-00049y-Lr; Tue, 21 Mar 2006 16:54:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLooI-00045w-04 for ecrit@ietf.org; Tue, 21 Mar 2006 16:54:38 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLooG-00054d-P2 for ecrit@ietf.org; Tue, 21 Mar 2006 16:54:37 -0500 Received: from [130.129.130.179] ([::ffff:130.129.130.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 21 Mar 2006 16:53:43 -0500 id 015880D4.442075E7.00002195 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <41B5FCF2-EA16-41DA-997A-750A2B4C2620@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] On DDDS discovery Date: Tue, 21 Mar 2006 16:54:34 -0500 To: "Thomson, Martin" X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: ecrit-bounces@ietf.org On Mar 21, 2006, at 3:34 PM, Thomson, Martin wrote: > A small update to RFC 3958, one that the authors agree would be > (relatively) easy to acheive and quite desirable, is to add support > for URI results (the "U" flag). Yes, and to clarify a misunderstanding in the session today... the authors of RFC 3958 do support the addition of the U flag. That is the opposite of what people claimed they heard. > The only thing that this solution doesn't include is the way that > the path component of the URI is populated with the service tag > ("sos", "sos.fire", etc...). Personally, even though I understand > some of the benefits of this approach, I don't think that this is > the place for that sort of information. That is information for > request bodies and the LoST protocol. These parameters can form > part of the request URI using the above results as a base URI, but > if the URI contains protocol data, its format should be specified > in a protocol document, not DNS. I totally agree. The interactions for this belong in LoST where there is better flexibility to apply this to the mapping. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Mar 21 22:51:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLuNH-0006Es-Qd; Tue, 21 Mar 2006 22:51:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FLuNG-0006CI-6X for ecrit@ietf.org; Tue, 21 Mar 2006 22:51:06 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FLuNE-0001uV-Sc for ecrit@ietf.org; Tue, 21 Mar 2006 22:51:06 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2M3p3cL024773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 21 Mar 2006 22:51:04 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2M3p3pY006978; Tue, 21 Mar 2006 22:51:03 -0500 Message-ID: <4420C9A8.2030108@cs.columbia.edu> Date: Tue, 21 Mar 2006 22:51:04 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] On DDDS discovery References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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: , Errors-To: ecrit-bounces@ietf.org Maybe it's a useful to step back a minute and look at possible requirements. I'd like the DDDS mechanism to address two requirements: (1) It should be possible to have other mapping protocols in the future, beyond just different encodings than, say, WSDL or plain HTTP. (2) It must be possible to have different services resolve to different mapping servers. A fictitious "doctor locator service" is likely to use a completely different mapping hierarchy than emergency services. Indeed, for a pizza delivery service, you might have one run by Pizza Hut and one run by Domino's. I'm not suggesting these are necessarily good examples of service URNs, but provide the flavor. I chose the should/must difference intentionally, i.e., I don't quite care about (1) as much as (2). For (2), we can either have DHCP or SIP configuration point to different DNS records for each service or we need to be able to handle this by NAPTR indirection, e.g., that my ISP or VSP domain points to their preferred mapping servers for a set of services. From my reading of 3598, I have concerns. In particular, Section 6.1 says: The Application Unique String is domain label for which an authoritative server for a particular service is sought. This is *not* quite what we want, at least if we want to incorporate the service itself into the server selection decision. If all of the server selection decision based on services is punted to DHCP or SIP-configuration, it is not clear to me that we need NAPTR indirection at all, since that first step might as well include the protocol name and we can directly proceed to SRV, which is simpler still. One possible approach is to define the service string as something like MP.sos.fire:LOST.http I don't know if that fits into the 3589 framework. (You'd have to define prune-back matching, i.e., if MP.sos.fire doesn't exist, try MP.sos.) Henning Thomson, Martin wrote: > In relation to my suggestion that S-NAPTR be used for discovery of > LoST. > > The main argument I heard against this was that it could delay the > service URN document, which is important and already running slightly > late -- a fair comment. In light of the fact that the discovery > section is now being moved to the LoST draft, which is less > constrained by time, I would like to re-float the argument. > > S-NAPTR simplifies the deployment of NAPTR. For LoST, I don't see > any need for the extra features that are excluded from the S-NAPTR > profile. S-NAPTR would reduce the complexity of resolvers and the > provisioning/data management effort at the DNS. A better argument > for the use of S-NAPTR is in RFC 3958 (Section 5). > > A small update to RFC 3958, one that the authors agree would be > (relatively) easy to acheive and quite desirable, is to add support > for URI results (the "U" flag). > > I do have a draft (available on request - it needs a rewrite) that > includes the both the change to S-NAPTR and additional information > that can be used to retrieve a service URI or a WSDL document that > describes the service in more detail. > > The following example might apply to LoST: example.com. ;; > order weight flags service regexp ;; > replacement IN NAPTR 100 10 "U" "LOST:https" "" ( > "https://ws.example.com/services/myws" ) IN NAPTR 200 10 "U" > "LOST:http" "" ( "http://ws.example.com/services/myws" ) > > This example uses a set of newly defined S-NAPTR application protocol > tags. SOAP and BEEP was the other option. The result is the base > URI for the service. > > The other option is to retrieve a WSDL document for the service that > can include additional information about the service: > > example.com. ;; order weight flags service regexp ;; > replacement IN NAPTR 100 10 "U" "LOST:WSDL" "" ( > "https://ws.example.com/wsdl/lost.wsdl" ) > > The only thing that this solution doesn't include is the way that the > path component of the URI is populated with the service tag ("sos", > "sos.fire", etc...). Personally, even though I understand some of > the benefits of this approach, I don't think that this is the place > for that sort of information. That is information for request bodies > and the LoST protocol. These parameters can form part of the request > URI using the above results as a base URI, but if the URI contains > protocol data, its format should be specified in a protocol document, > not DNS. > > Regards, Martin > > > > > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you > have received it in error, please notify the sender immediately and > delete the original. Any unauthorized use of this email is > prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ 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 Wed Mar 22 07:40:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM2dL-0006Xj-Dd; Wed, 22 Mar 2006 07:40:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM2dK-0006TV-1M for ecrit@ietf.org; Wed, 22 Mar 2006 07:40:14 -0500 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM2dI-0005Jv-Qa for ecrit@ietf.org; Wed, 22 Mar 2006 07:40:14 -0500 Received: from [130.129.130.179] ([::ffff:130.129.130.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 22 Mar 2006 07:39:19 -0500 id 01588166.44214577.00004037 In-Reply-To: <4420C9A8.2030108@cs.columbia.edu> References: <4420C9A8.2030108@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <915C93C4-66F4-4607-8DEF-D801791ABCE0@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] On DDDS discovery Date: Wed, 22 Mar 2006 07:40:03 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ecrit@ietf.org, "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org On Mar 21, 2006, at 10:51 PM, Henning Schulzrinne wrote: > One possible approach is to define the service string as something > like > > MP.sos.fire:LOST.http > > I don't know if that fits into the 3589 framework. (You'd have to > define prune-back matching, i.e., if MP.sos.fire doesn't exist, try > MP.sos.) Yes, you could do this with 3958, but I think it would be a hack and therefore probably inappropriate. But I thought Martin's whole point was that you don't need to do it since the service URN is being handed to the mapping server in the LoST protocol itself. And I have to confess that I now find the purpose of the service URN confusing. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 09:48:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM4db-00008A-H8; Wed, 22 Mar 2006 09:48:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM4dZ-00007V-Oc for ecrit@ietf.org; Wed, 22 Mar 2006 09:48:37 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM4dY-0002Bi-Gu for ecrit@ietf.org; Wed, 22 Mar 2006 09:48:37 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MEmVcL028409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 09:48:32 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MEmVjW015715; Wed, 22 Mar 2006 09:48:31 -0500 Message-ID: <442163C0.1080100@cs.columbia.edu> Date: Wed, 22 Mar 2006 09:48:32 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] On DDDS discovery References: <4420C9A8.2030108@cs.columbia.edu> <915C93C4-66F4-4607-8DEF-D801791ABCE0@hxr.us> In-Reply-To: <915C93C4-66F4-4607-8DEF-D801791ABCE0@hxr.us> 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, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ecrit@ietf.org, "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org Andrew, you didn't answer my two requirements earlier in that message, namely (restated), in particular, that I think that we need to be able to support having different resolvers for different services and that a seeker needs to be able to identify those automatically and easily. I'm also not quite convinced yet that we want to tie the service URN completely to one lookup protocol, forever and across all services. This seems unnecessary and unwise. Henning Andrew Newton wrote: > > On Mar 21, 2006, at 10:51 PM, Henning Schulzrinne wrote: >> One possible approach is to define the service string as something like >> >> MP.sos.fire:LOST.http >> >> I don't know if that fits into the 3589 framework. (You'd have to >> define prune-back matching, i.e., if MP.sos.fire doesn't exist, try >> MP.sos.) > > Yes, you could do this with 3958, but I think it would be a hack and > therefore probably inappropriate. But I thought Martin's whole point > was that you don't need to do it since the service URN is being handed > to the mapping server in the LoST protocol itself. And I have to > confess that I now find the purpose of the service URN confusing. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 10:27:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5FL-0007gS-A3; Wed, 22 Mar 2006 10:27:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5FJ-0007g8-5a for ecrit@ietf.org; Wed, 22 Mar 2006 10:27:37 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5FH-0003dr-UP for ecrit@ietf.org; Wed, 22 Mar 2006 10:27:37 -0500 Received: from [130.129.130.179] ([::ffff:130.129.130.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 22 Mar 2006 10:26:42 -0500 id 0158816F.44216CB2.00005FC8 In-Reply-To: <442163C0.1080100@cs.columbia.edu> References: <4420C9A8.2030108@cs.columbia.edu> <915C93C4-66F4-4607-8DEF-D801791ABCE0@hxr.us> <442163C0.1080100@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <15F2AB55-E904-4E42-8624-DA9A172DE162@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] On DDDS discovery Date: Wed, 22 Mar 2006 10:27:33 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: ecrit@ietf.org, "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org On Mar 22, 2006, at 9:48 AM, Henning Schulzrinne wrote: > you didn't answer my two requirements earlier in that message, > namely (restated), in particular, that I think that we need to be > able to support having different resolvers for different services > and that a seeker needs to be able to identify those automatically > and easily. Sorry. To be specific to your earlier email, I believe both items are covered by 3958. However, this text says something different. I don't know what you mean by "resolver" because we are talking about DNS resource records and the term "resolver" has a very specific meaning in that context... one I'm hoping you are not suggesting. > I'm also not quite convinced yet that we want to tie the service > URN completely to one lookup protocol, forever and across all > services. This seems unnecessary and unwise. Neither Martin nor I are suggesting any such thing, and 3958 is obviously not saying this as the examples in that RFC are explicitly about using multiple protocols for services. At the moment, I am not exactly comfortable suggesting that 3958 is applicable but the same goes for DDDS in general. That is why I said I am confused about where this URN is being used and for what purpose. Is this about describing the service universally or about describing a service contextually? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 10:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5GZ-000818-L4; Wed, 22 Mar 2006 10:28:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5GY-000813-VO for ecrit@ietf.org; Wed, 22 Mar 2006 10:28:54 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5GX-0003gw-P8 for ecrit@ietf.org; Wed, 22 Mar 2006 10:28:54 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MFRccL008391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 22 Mar 2006 10:28:52 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MFRRGp015873 for ; Wed, 22 Mar 2006 10:27:37 -0500 Message-ID: <44216CE1.8030805@cs.columbia.edu> Date: Wed, 22 Mar 2006 10:27:29 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "'ecrit@ietf.org'" 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, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ecrit] Thought on citizen notification & LoST 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: , Errors-To: ecrit-bounces@ietf.org Just a thought on the citizen notification topic that was briefly mentioned yesterday: I think that LoST can actually be quite useful there. The main problem for citizen notification is to find out where to get notifications since it will, in general, be very difficult for authorities to find out what devices are within their geographic reach. (Clearly, this is possible for cell phones and maybe for some residential access, but requires tight coordination of the government authorities with all network providers.) The solution is simple: When querying LoST, get back a SIP URI or email address or other identifier that one can subscribe to and then get notifications for that geographic area. This is not in scope, but it might be worth keeping in mind, particularly since it seems to fit the existing model. (We'd probably define a new service URN service for that.) Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 10:42:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5Te-0000qu-J8; Wed, 22 Mar 2006 10:42:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5Td-0000qp-P6 for ecrit@ietf.org; Wed, 22 Mar 2006 10:42:25 -0500 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5Tc-0004FM-Id for ecrit@ietf.org; Wed, 22 Mar 2006 10:42:25 -0500 Received: from [130.129.130.179] ([::ffff:130.129.130.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 22 Mar 2006 10:41:31 -0500 id 0158816F.4421702B.0000639A In-Reply-To: <44216CE1.8030805@cs.columbia.edu> References: <44216CE1.8030805@cs.columbia.edu> Mime-Version: 1.0 Message-Id: <0EF52AE9-0E26-475F-AAF9-E3C6038908C1@hxr.us> From: Andrew Newton Subject: Re: [Ecrit] Thought on citizen notification & LoST Date: Wed, 22 Mar 2006 10:42:21 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Content-Type: multipart/mixed; boundary="===============0870600949==" Errors-To: ecrit-bounces@ietf.org This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --===============0870600949== Content-Type: multipart/alternative; boundary="=_zeke.ecotroph.net-25500-1143042091-0001-2" This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zeke.ecotroph.net-25500-1143042091-0001-2 Content-Type: text/plain; charset=us-ascii; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: > This is not in scope, but it might be worth keeping in mind, > particularly since it seems to fit the existing model. (We'd > probably define a new service URN service for that.) I was thinking exactly that. urn:service.sos.disaster-notice. And defining it in such a way, I think it might be within the scope of the working group. -andy --=_zeke.ecotroph.net-25500-1143042091-0001-2 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mime-Autoconverted: from quoted-printable to quoted-printable by courier 0.53.0
On Mar 22, 2006, at 10:= 27 AM, Henning Schulzrinne wrote:

= This is not in scope, but it might be worth keeping in mind, particularly= since it seems to fit the existing model. (We'd probably define a new se= rvice URN service for that.)



--=_zeke.ecotroph.net-25500-1143042091-0001-2-- --===============0870600949== 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 --===============0870600949==-- From ecrit-bounces@ietf.org Wed Mar 22 10:43:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5UZ-0001ny-3z; Wed, 22 Mar 2006 10:43:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM5UY-0001nt-QD for ecrit@ietf.org; Wed, 22 Mar 2006 10:43:22 -0500 Received: from test-iport-1.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM5UW-0004HJ-Dc for ecrit@ietf.org; Wed, 22 Mar 2006 10:43:22 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by test-iport-1.cisco.com with ESMTP; 22 Mar 2006 07:43:19 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2MFhJ7T028528; Wed, 22 Mar 2006 07:43:19 -0800 (PST) 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); Wed, 22 Mar 2006 07:43:19 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 07:43:14 -0800 From: "Marc Linsner" To: "'Henning Schulzrinne'" , Subject: RE: [Ecrit] Thought on citizen notification & LoST Date: Wed, 22 Mar 2006 10:43:12 -0500 Message-ID: <00c101c64dc7$57461840$8053150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <44216CE1.8030805@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZNxXVjy340PJrRTwy3IwoLxfXjTgAAbVdw X-OriginalArrivalTime: 22 Mar 2006 15:43:18.0846 (UTC) FILETIME=[577FC5E0:01C64DC7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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: , Errors-To: ecrit-bounces@ietf.org Or receive back the multicast S,G to 'tune into"...... -Marc- > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, March 22, 2006 10:27 AM > To: 'ecrit@ietf.org' > Subject: [Ecrit] Thought on citizen notification & LoST > > Just a thought on the citizen notification topic that was > briefly mentioned yesterday: I think that LoST can actually > be quite useful there. The main problem for citizen > notification is to find out where to get notifications since > it will, in general, be very difficult for authorities to > find out what devices are within their geographic reach. > (Clearly, this is possible for cell phones and maybe for some > residential access, but requires tight coordination of the > government authorities with all network providers.) > > The solution is simple: When querying LoST, get back a SIP > URI or email address or other identifier that one can > subscribe to and then get notifications for that geographic area. > > This is not in scope, but it might be worth keeping in mind, > particularly since it seems to fit the existing model. (We'd > probably define a new service URN service for that.) > > Henning > > _______________________________________________ > 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 Wed Mar 22 11:17:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM61F-0003Fa-MD; Wed, 22 Mar 2006 11:17:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM61E-0003FV-Uw for ecrit@ietf.org; Wed, 22 Mar 2006 11:17:08 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM61D-0005pJ-O9 for ecrit@ietf.org; Wed, 22 Mar 2006 11:17:08 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MG9bcL018722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 11:09:37 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MG9Pi0015925; Wed, 22 Mar 2006 11:09:25 -0500 Message-ID: <442176B7.4010306@cs.columbia.edu> Date: Wed, 22 Mar 2006 11:09:27 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Thought on citizen notification & LoST References: <00c101c64dc7$57461840$8053150a@amer.cisco.com> In-Reply-To: <00c101c64dc7$57461840$8053150a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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: , Errors-To: ecrit-bounces@ietf.org Most likely a pointer to SDP in that case, since a multicast address by itself probably isn't sufficient to communicate. Marc Linsner wrote: > Or receive back the multicast S,G to 'tune into"...... > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 11:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM640-0006r3-PS; Wed, 22 Mar 2006 11:20:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM640-0006q1-1S for ecrit@ietf.org; Wed, 22 Mar 2006 11:20:00 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM63x-0005wC-OU for ecrit@ietf.org; Wed, 22 Mar 2006 11:20:00 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM63q-00036K-Eg; Wed, 22 Mar 2006 10:19:50 -0600 From: "Brian Rosen" To: "'Andrew Newton'" , "'Henning Schulzrinne'" Subject: RE: [Ecrit] Thought on citizen notification & LoST Date: Wed, 22 Mar 2006 11:19:48 -0500 Message-ID: <033301c64dcc$72c4b900$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZNxziYi3k18yVnRKuzbtR8/DECcgAAyszw In-Reply-To: <0EF52AE9-0E26-475F-AAF9-E3C6038908C1@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Generally, I think this is a good idea. A problem with it is that what you REALLY want is an opt-in of the form "send me notices of emergencies where I am at the moment," which is fairly straightforward, but you also want one that was "send me notices of emergencies where my child is at the moment", which is less straightforward. The general way notification services that exist now work is that you register with an AREA of interest, and a notifier registers with an area of service. For example, Contra Costa County Sheriffs Office registers as a recipient of weather events within Contra Costa County. NOAA registers as a notifier of weather events for all of the United States. If NOAA issues an alert for four counties including Contra Costa County; the Sheriffs office gets that alert. Look at EPAD at Comcare (www.comcare.org/epad.html). Nevertheless, Henning has talked about keeping "liveness" of a mapping by tracking location relative to the service boundary of, say, a PSAP. I'm still not sure how that works, but if it did, it would be the kind of thing we want for this use. Brian ________________________________________ From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, March 22, 2006 10:42 AM To: Henning Schulzrinne Cc: 'ecrit@ietf.org' Subject: Re: [Ecrit] Thought on citizen notification & LoST On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: This is not in scope, but it might be worth keeping in mind, particularly since it seems to fit the existing model. (We'd probably define a new service URN service for that.) I was thinking exactly that. urn:service.sos.disaster-notice. And defining it in such a way, I think it might be within the scope of the working group. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 11:22:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM66h-0000Yv-M2; Wed, 22 Mar 2006 11:22:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM66g-0000Yq-Ha for ecrit@ietf.org; Wed, 22 Mar 2006 11:22:46 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM66f-0006Ae-Bc for ecrit@ietf.org; Wed, 22 Mar 2006 11:22:46 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MGIwcL020506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 11:22:42 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MGIvL4015974; Wed, 22 Mar 2006 11:18:58 -0500 Message-ID: <442178F3.6050805@cs.columbia.edu> Date: Wed, 22 Mar 2006 11:18:59 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Thought on citizen notification & LoST References: <44216CE1.8030805@cs.columbia.edu> <0EF52AE9-0E26-475F-AAF9-E3C6038908C1@hxr.us> In-Reply-To: <0EF52AE9-0E26-475F-AAF9-E3C6038908C1@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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: , Errors-To: ecrit-bounces@ietf.org The two services (citizen-to-authority and authority-to-citizen) are probably sufficiently distinct that something like urn:service:alert.chemical might be a better fit, where 'chemical' might identify the type of emergency I'm interested in. For example, the person responsible for the air intake valves at the Pentagon may not be particularly concerned with 'amber alerts' (for non-US audience: These are alerts for missing children.) > I was thinking exactly that. urn:service.sos.disaster-notice. And > defining it in such a way, I think it might be within the scope of the > working group. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 11:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6F7-00076g-0I; Wed, 22 Mar 2006 11:31:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6F5-00076Y-5a for ecrit@ietf.org; Wed, 22 Mar 2006 11:31:27 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6F3-0006iC-Re for ecrit@ietf.org; Wed, 22 Mar 2006 11:31:27 -0500 Received: from dhcp-wireless-134-205.ietf65.org ([130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FM6F1-000464-9x; Wed, 22 Mar 2006 10:31:23 -0600 Message-ID: <44217BD8.7060306@ntt-at.com> Date: Wed, 22 Mar 2006 08:31:20 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Thought on citizen notification & LoST References: <033301c64dcc$72c4b900$73818182@cis.neustar.com> In-Reply-To: <033301c64dcc$72c4b900$73818182@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Errors-To: ecrit-bounces@ietf.org Hi Brian; I think Rohan was suggesting some draft for filtering location info and event package for delivering location for the purpose of "I want to know where foo is.". I guess one can use the information attained through the event package mentioned above and plug that into what henning is suggesting. Regards Shida Brian Rosen wrote: > Generally, I think this is a good idea. > > A problem with it is that what you REALLY want is an opt-in of the form > "send me notices of emergencies where I am at the moment," which is fairly > straightforward, but you also want one that was "send me notices of > emergencies where my child is at the moment", which is less straightforward. > > > The general way notification services that exist now work is that you > register with an AREA of interest, and a notifier registers with an area of > service. For example, Contra Costa County Sheriffs Office registers as a > recipient of weather events within Contra Costa County. NOAA registers as a > notifier of weather events for all of the United States. If NOAA issues an > alert for four counties including Contra Costa County; the Sheriffs office > gets that alert. Look at EPAD at Comcare (www.comcare.org/epad.html). > > Nevertheless, Henning has talked about keeping "liveness" of a mapping by > tracking location relative to the service boundary of, say, a PSAP. I'm > still not sure how that works, but if it did, it would be the kind of thing > we want for this use. > > Brian > > > ________________________________________ > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, March 22, 2006 10:42 AM > To: Henning Schulzrinne > Cc: 'ecrit@ietf.org' > Subject: Re: [Ecrit] Thought on citizen notification & LoST > > > On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: > > > This is not in scope, but it might be worth keeping in mind, particularly > since it seems to fit the existing model. (We'd probably define a new > service URN service for that.) > > I was thinking exactly that. urn:service.sos.disaster-notice. And defining > it in such a way, I think it might be within the scope of the working group. > > -andy > > > _______________________________________________ > 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 Wed Mar 22 11:39:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6N0-0004sR-KR; Wed, 22 Mar 2006 11:39:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6Mz-0004rR-Gu for ecrit@ietf.org; Wed, 22 Mar 2006 11:39:37 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6My-00077H-8u for ecrit@ietf.org; Wed, 22 Mar 2006 11:39:37 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MGdWcL025968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 11:39:33 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MGdVs9016063; Wed, 22 Mar 2006 11:39:32 -0500 Message-ID: <44217DC5.8050203@cs.columbia.edu> Date: Wed, 22 Mar 2006 11:39:33 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Thought on citizen notification & LoST References: <033301c64dcc$72c4b900$73818182@cis.neustar.com> In-Reply-To: <033301c64dcc$72c4b900$73818182@cis.neustar.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, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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: , Errors-To: ecrit-bounces@ietf.org I agree that you need to be able to get alerts for other places. There are two cases: (1) "Alert me for point X" (2) "Alert me for area Y (polygon)" I think (1) is easy to handle in LoST, regardless of whether X happens to be my current location or that of some other party. Obviously, the notification for point X might cover a whole county or larger region. The same region hinting would apply here, i.e., the response from LoST would indicate the polygon or civic address coordinates where the same notification address applies. There is no need to re-query until you or your child move outside that area. (2) is somewhat harder, as the polygon may have many notification addresses if it spans multiple jurisdictions. I'm less sure that this is actually needed in practice. Henning > A problem with it is that what you REALLY want is an opt-in of the form > "send me notices of emergencies where I am at the moment," which is fairly > straightforward, but you also want one that was "send me notices of > emergencies where my child is at the moment", which is less straightforward. > > > The general way notification services that exist now work is that you > register with an AREA of interest, and a notifier registers with an area of > service. For example, Contra Costa County Sheriffs Office registers as a > recipient of weather events within Contra Costa County. NOAA registers as a > notifier of weather events for all of the United States. If NOAA issues an > alert for four counties including Contra Costa County; the Sheriffs office > gets that alert. Look at EPAD at Comcare (www.comcare.org/epad.html). > > Nevertheless, Henning has talked about keeping "liveness" of a mapping by > tracking location relative to the service boundary of, say, a PSAP. I'm > still not sure how that works, but if it did, it would be the kind of thing > we want for this use. > > Brian > > > ________________________________________ > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, March 22, 2006 10:42 AM > To: Henning Schulzrinne > Cc: 'ecrit@ietf.org' > Subject: Re: [Ecrit] Thought on citizen notification & LoST > > > On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: > > > This is not in scope, but it might be worth keeping in mind, particularly > since it seems to fit the existing model. (We'd probably define a new > service URN service for that.) > > I was thinking exactly that. urn:service.sos.disaster-notice. And defining > it in such a way, I think it might be within the scope of the working group. > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 11:42:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6Pu-0006OT-2m; Wed, 22 Mar 2006 11:42:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6Ps-0006OO-Tt for ecrit@ietf.org; Wed, 22 Mar 2006 11:42:36 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6Pq-0007LR-I5 for ecrit@ietf.org; Wed, 22 Mar 2006 11:42:36 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM6Ph-0005Df-1L; Wed, 22 Mar 2006 10:42:27 -0600 From: "Brian Rosen" To: "'Shida Schubert'" Subject: RE: [Ecrit] Thought on citizen notification & LoST Date: Wed, 22 Mar 2006 11:42:24 -0500 Message-ID: <033701c64dcf$9cf15af0$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZNzgw0AP6hIrwRQjOsuv4hOJS2HAAANHXw In-Reply-To: <44217BD8.7060306@ntt-at.com> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org What I don't think would work would be a service that got (filtered) notifications of current location changes, and for each of those notifications, queried LoST to determine the service notifier, and when it changed, initiated a new subscription to the new notifier. Take an example: you are on a mobile device, near a border, and moving. When you first start, you are in one country, and you subscribe to that country's notification service. No problem. But, you are moving. Some service is subscribed to your presence and tracking you (opt-in of course). Does that service have to continuously query using LoST to determine that you have crossed the boundary? Brian -----Original Message----- From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, March 22, 2006 11:31 AM To: br@brianrosen.net Cc: 'Andrew Newton'; 'Henning Schulzrinne'; ecrit@ietf.org Subject: Re: [Ecrit] Thought on citizen notification & LoST Hi Brian; I think Rohan was suggesting some draft for filtering location info and event package for delivering location for the purpose of "I want to know where foo is.". I guess one can use the information attained through the event package mentioned above and plug that into what henning is suggesting. Regards Shida Brian Rosen wrote: > Generally, I think this is a good idea. > > A problem with it is that what you REALLY want is an opt-in of the form > "send me notices of emergencies where I am at the moment," which is fairly > straightforward, but you also want one that was "send me notices of > emergencies where my child is at the moment", which is less straightforward. > > > The general way notification services that exist now work is that you > register with an AREA of interest, and a notifier registers with an area of > service. For example, Contra Costa County Sheriffs Office registers as a > recipient of weather events within Contra Costa County. NOAA registers as a > notifier of weather events for all of the United States. If NOAA issues an > alert for four counties including Contra Costa County; the Sheriffs office > gets that alert. Look at EPAD at Comcare (www.comcare.org/epad.html). > > Nevertheless, Henning has talked about keeping "liveness" of a mapping by > tracking location relative to the service boundary of, say, a PSAP. I'm > still not sure how that works, but if it did, it would be the kind of thing > we want for this use. > > Brian > > > ________________________________________ > From: Andrew Newton [mailto:andy@hxr.us] > Sent: Wednesday, March 22, 2006 10:42 AM > To: Henning Schulzrinne > Cc: 'ecrit@ietf.org' > Subject: Re: [Ecrit] Thought on citizen notification & LoST > > > On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: > > > This is not in scope, but it might be worth keeping in mind, particularly > since it seems to fit the existing model. (We'd probably define a new > service URN service for that.) > > I was thinking exactly that. urn:service.sos.disaster-notice. And defining > it in such a way, I think it might be within the scope of the working group. > > -andy > > > _______________________________________________ > 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 Wed Mar 22 11:52:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6ZC-0003X0-6L; Wed, 22 Mar 2006 11:52:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6ZA-0003Wt-TW for ecrit@ietf.org; Wed, 22 Mar 2006 11:52:12 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FM6Z9-0007jo-F6 for ecrit@ietf.org; Wed, 22 Mar 2006 11:52:12 -0500 Received: (qmail invoked by alias); 22 Mar 2006 16:52:10 -0000 Received: from DHCP-Wireless-129-200.ietf65.org (EHLO [130.129.129.200]) [130.129.129.200] by mail.gmx.net (mp001) with SMTP; 22 Mar 2006 17:52:10 +0100 X-Authenticated: #29516787 Message-ID: <442180BD.7090707@gmx.net> Date: Wed, 22 Mar 2006 10:52:13 -0600 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Subject: [Ecrit] ECRIT Working Group Session: Summary 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: , Errors-To: ecrit-bounces@ietf.org Hi all, at the ECRIT WG meeting yesterday we discussed a few aspects and we would like to confirm them on the mailing list: * Requirements ************** http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-06.txt Issues raised during WGLC will be added to the issue tracker, will be discussed and a new draft version will be resubmitted very soon. Roger will discuss the align the usage of RFC 2119 language in the Security Threats draft and the Requirements draft. * Security Threats ****************** http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security-threats-03.txt Tom will reflect comments regarding the security aspects of a proxy initiating the mapping protocol interaction. Text might need to go to the requirements document as well. * A Uniform Resource Name for Services ************************************** http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-01.txt Based on long discussions during the meeting Henning will send a summary of the call identification with a suggested approach on resolving the issue. Discussions during the meeting already pointed to a preferred approach but more discussions might be needed. Text about DDDS resolution will be removed from the draft and moved to the LoST document. According to our charter milestones the document has to be finished soon. * LoST ****** http://www.ietf-ecrit.org/cache/draft-hardie-ecrit-lost-00.txt The participants showed interest to make LoST a working group item and to work on it aggressively. * Mapping Architecture and Framework ************************************ http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-mapping-arch-00.txt The working group expressed interest in working on such a document. Since this work is not captured by the current charter the chairs will compile a proposal for a modified charter. * ECRIT Big Picture ******************* There was interest in the past to write a document that explains the big picture. The chairs will form a design team to work on such a document. * Phone BCP *********** http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-00.txt The working group expressed interest in working on such a document. Since this work is not captured by the current charter the chairs will compile a proposal for a modified charter. *Analyzing ECRIT Mapping of a Location to an Emergency URI for Emergency Calling ************************************************************************ http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-events-00.txt This document will be discussed further on the mailing list. * Authority To Citizen Notification *********************************** This presentation was purely informational for the working group. Interested parties should contact the chairs and/or Steve Norreys. * 3GPP Emergency Services and ECRIT work **************************************** Discussions about 3GPP Emergency Service work revealed the need to establish a closer interaction between ECRIT and the respective 3GPP groups. The chairs will think about a possible way forward. Please let us know if you have further comments. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 12:12:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6sX-0002yy-C4; Wed, 22 Mar 2006 12:12:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6sW-0002xt-Ui for ecrit@ietf.org; Wed, 22 Mar 2006 12:12:12 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6sV-0000Ej-Jv for ecrit@ietf.org; Wed, 22 Mar 2006 12:12:12 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2006 09:12:11 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="419254381:sNHT28103084" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2MHBw81029336 for ; Wed, 22 Mar 2006 09:12:11 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:12:04 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:12:03 -0800 From: "Marc Linsner" To: Date: Wed, 22 Mar 2006 12:12:03 -0500 Message-ID: <003f01c64dd3$bdf758e0$e07060cc@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkA== X-OriginalArrivalTime: 22 Mar 2006 17:12:03.0956 (UTC) FILETIME=[BD831340:01C64DD3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ecrit] Dial Strings... 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: , Errors-To: ecrit-bounces@ietf.org I want to float an idea wrt dial strings. We had some conversation for some time as to the value of the UA understanding local emergency dial strings. Since we're at the end of the requirements for LoST, please express opinion on whether distributing local dial strings via LoST is feasible and worthy of adding to our requirements draft. One example: UA boots --> UA launches LoST query and receives location validation, PSAP uri (for fallback), and local dial strings. Thanks, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 12:12:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6tA-0004HU-WD; Wed, 22 Mar 2006 12:12:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6t9-0004Gy-DC for ecrit@ietf.org; Wed, 22 Mar 2006 12:12:51 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6t8-0000FR-24 for ecrit@ietf.org; Wed, 22 Mar 2006 12:12:51 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MHCkcL003278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 12:12:46 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MHChYZ016149; Wed, 22 Mar 2006 12:12:44 -0500 Message-ID: <4421858D.1050600@cs.columbia.edu> Date: Wed, 22 Mar 2006 12:12:45 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Thought on citizen notification & LoST References: <033701c64dcf$9cf15af0$73818182@cis.neustar.com> In-Reply-To: <033701c64dcf$9cf15af0$73818182@cis.neustar.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, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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: , Errors-To: ecrit-bounces@ietf.org You seem to have a mediated model in mind where the end user subscribes to the 'emergency alerting service' and the mediator then provides and possibly aggregates alerts from multiple sources. The mediator obviously needs to subscribe to my location to make this work, like you indicate. In that model, the mediating service would get the location notifications for you (and probably lots of other people), query LoST and cache the results. If somebody shows up in a new area, it changes the alert notification or the alert subscriptions. This certainly doesn't require re-querying LoST for each border crossing. Henning Brian Rosen wrote: > What I don't think would work would be a service that got (filtered) > notifications of current location changes, and for each of those > notifications, queried LoST to determine the service notifier, and when it > changed, initiated a new subscription to the new notifier. > > Take an example: you are on a mobile device, near a border, and moving. > When you first start, you are in one country, and you subscribe to that > country's notification service. No problem. But, you are moving. Some > service is subscribed to your presence and tracking you (opt-in of course). > Does that service have to continuously query using LoST to determine that > you have crossed the boundary? > > Brian > > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Wednesday, March 22, 2006 11:31 AM > To: br@brianrosen.net > Cc: 'Andrew Newton'; 'Henning Schulzrinne'; ecrit@ietf.org > Subject: Re: [Ecrit] Thought on citizen notification & LoST > > > Hi Brian; > > I think Rohan was suggesting some draft for filtering location info > and event package for delivering location for the purpose of "I > want to know where foo is.". I guess one can use the information > attained through the event package mentioned above and plug > that into what henning is suggesting. > > Regards > Shida > > Brian Rosen wrote: >> Generally, I think this is a good idea. >> >> A problem with it is that what you REALLY want is an opt-in of the form >> "send me notices of emergencies where I am at the moment," which is fairly >> straightforward, but you also want one that was "send me notices of >> emergencies where my child is at the moment", which is less > straightforward. >> >> The general way notification services that exist now work is that you >> register with an AREA of interest, and a notifier registers with an area > of >> service. For example, Contra Costa County Sheriffs Office registers as a >> recipient of weather events within Contra Costa County. NOAA registers as > a >> notifier of weather events for all of the United States. If NOAA issues > an >> alert for four counties including Contra Costa County; the Sheriffs office >> gets that alert. Look at EPAD at Comcare (www.comcare.org/epad.html). >> >> Nevertheless, Henning has talked about keeping "liveness" of a mapping by >> tracking location relative to the service boundary of, say, a PSAP. I'm >> still not sure how that works, but if it did, it would be the kind of > thing >> we want for this use. >> >> Brian >> >> >> ________________________________________ >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Wednesday, March 22, 2006 10:42 AM >> To: Henning Schulzrinne >> Cc: 'ecrit@ietf.org' >> Subject: Re: [Ecrit] Thought on citizen notification & LoST >> >> >> On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: >> >> >> This is not in scope, but it might be worth keeping in mind, particularly >> since it seems to fit the existing model. (We'd probably define a new >> service URN service for that.) >> >> I was thinking exactly that. urn:service.sos.disaster-notice. And defining >> it in such a way, I think it might be within the scope of the working > group. >> -andy >> >> >> _______________________________________________ >> 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 Wed Mar 22 12:19:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6zm-0008Fz-BJ; Wed, 22 Mar 2006 12:19:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM6zl-0008Fu-0l for ecrit@ietf.org; Wed, 22 Mar 2006 12:19:41 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM6zj-0000N6-Pz for ecrit@ietf.org; Wed, 22 Mar 2006 12:19:40 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MHJccL005235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 12:19:38 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MHJcYa016167; Wed, 22 Mar 2006 12:19:38 -0500 Message-ID: <4421872B.3000304@cs.columbia.edu> Date: Wed, 22 Mar 2006 12:19:39 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Dial Strings... References: <003f01c64dd3$bdf758e0$e07060cc@amer.cisco.com> In-Reply-To: <003f01c64dd3$bdf758e0$e07060cc@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: ecrit-bounces@ietf.org Note that this works for both local and home dial strings. The UA makes two queries to LoST in this model if home country != visited country: (1) one with country=home country (2) another one with country=visited country In both cases, they can either get back a single dial string for the service indicated or possibly a list of all dial strings if these differ across emergency services (fire, police, etc.). Henning Marc Linsner wrote: > I want to float an idea wrt dial strings. > > We had some conversation for some time as to the value of the UA > understanding local emergency dial strings. Since we're at the end of the > requirements for LoST, please express opinion on whether distributing local > dial strings via LoST is feasible and worthy of adding to our requirements > draft. > > One example: UA boots --> UA launches LoST query and receives location > validation, PSAP uri (for fallback), and local dial strings. > > Thanks, > > -Marc- > > _______________________________________________ > 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 Wed Mar 22 12:23:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM730-0003Wa-1X; Wed, 22 Mar 2006 12:23:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM72z-0003WV-9r for ecrit@ietf.org; Wed, 22 Mar 2006 12:23:01 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM72x-0000Sl-Tr for ecrit@ietf.org; Wed, 22 Mar 2006 12:23:01 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 22 Mar 2006 09:22:59 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="419258178:sNHT29526420" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k2MHMxw1024274; Wed, 22 Mar 2006 09:22:59 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:22:59 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 09:22:58 -0800 From: "Marc Linsner" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 12:22:57 -0500 Message-ID: <004e01c64dd5$44654c60$e07060cc@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZN1NGBKWB6zUe8TTWvFRMd14dJHgAACzqg In-Reply-To: <4421872B.3000304@cs.columbia.edu> X-OriginalArrivalTime: 22 Mar 2006 17:22:58.0690 (UTC) FILETIME=[43C38E20:01C64DD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: ecrit-bounces@ietf.org Home dials strings *could* also be user-input-to-new-phone hardcoded. -Marc- > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Wednesday, March 22, 2006 12:20 PM > To: Marc Linsner > Cc: ecrit@ietf.org > Subject: Re: [Ecrit] Dial Strings... > > Note that this works for both local and home dial strings. > The UA makes two queries to LoST in this model if home > country != visited country: > > (1) one with country=home country > > (2) another one with country=visited country > > In both cases, they can either get back a single dial string > for the service indicated or possibly a list of all dial > strings if these differ across emergency services (fire, > police, etc.). > > Henning > > Marc Linsner wrote: > > I want to float an idea wrt dial strings. > > > > We had some conversation for some time as to the value of the UA > > understanding local emergency dial strings. Since we're at > the end of > > the requirements for LoST, please express opinion on whether > > distributing local dial strings via LoST is feasible and worthy of > > adding to our requirements draft. > > > > One example: UA boots --> UA launches LoST query and > receives location > > validation, PSAP uri (for fallback), and local dial strings. > > > > Thanks, > > > > -Marc- > > > > _______________________________________________ > > 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 Wed Mar 22 12:26:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM765-0005PY-Aw; Wed, 22 Mar 2006 12:26:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM764-0005PS-48 for ecrit@ietf.org; Wed, 22 Mar 2006 12:26:12 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FM762-0000Zy-OD for ecrit@ietf.org; Wed, 22 Mar 2006 12:26:12 -0500 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] Dial Strings... Date: Wed, 22 Mar 2006 18:30:10 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C491E@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Dial Strings... Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslx From: "Stastny Richard" To: "Marc Linsner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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: , Errors-To: ecrit-bounces@ietf.org I consider this very useful, and not much additional effort =20 It requires also on location infromation based on country It could be given back with the country default PSAP(s) if only the country is known =20 I think this was also in the original cc.sos.arpa proposal from Brian =20 The basic question is what happens if the local dialstring is clashing with other local numbers. THis may be left to the user client, but we should give some guidance here. =20 Richard ________________________________ Von: Marc Linsner [mailto:mlinsner@cisco.com] Gesendet: Mi 22.03.2006 18:12 An: ecrit@ietf.org Betreff: [Ecrit] Dial Strings... I want to float an idea wrt dial strings. We had some conversation for some time as to the value of the UA understanding local emergency dial strings. Since we're at the end of = the requirements for LoST, please express opinion on whether distributing = local dial strings via LoST is feasible and worthy of adding to our = requirements draft. One example: UA boots --> UA launches LoST query and receives location validation, PSAP uri (for fallback), and local dial strings. Thanks, -Marc- _______________________________________________ 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 Wed Mar 22 12:28:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM77u-00065r-AD; Wed, 22 Mar 2006 12:28:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM77t-00065m-QV for ecrit@ietf.org; Wed, 22 Mar 2006 12:28:05 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM77s-0000dL-Cr for ecrit@ietf.org; Wed, 22 Mar 2006 12:28:05 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM77i-0000oS-Cu; Wed, 22 Mar 2006 11:27:55 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" Subject: RE: [Ecrit] Thought on citizen notification & LoST Date: Wed, 22 Mar 2006 12:27:56 -0500 Message-ID: <037c01c64dd5$f7cc6c20$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZN09TIIUICVJx+Taq9xzedxsdR1wAAU65g In-Reply-To: <4421858D.1050600@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think you more or less answered the question earlier, when you described how LoST can return information that lets you determine locally if you are still in an area where the mapping remains valid. I'm still somewhat skeptical of how that works for geo (I'm guessing you have to return the entire service boundary of the service, which could be pretty large, and then the local decision is point-in-polygon). It's very nice where there are regular civic boundaries (for example, valid for the entire country/state/county...), which probably would be common. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wednesday, March 22, 2006 12:13 PM To: br@brianrosen.net Cc: 'Shida Schubert'; 'Andrew Newton'; ecrit@ietf.org Subject: Re: [Ecrit] Thought on citizen notification & LoST You seem to have a mediated model in mind where the end user subscribes to the 'emergency alerting service' and the mediator then provides and possibly aggregates alerts from multiple sources. The mediator obviously needs to subscribe to my location to make this work, like you indicate. In that model, the mediating service would get the location notifications for you (and probably lots of other people), query LoST and cache the results. If somebody shows up in a new area, it changes the alert notification or the alert subscriptions. This certainly doesn't require re-querying LoST for each border crossing. Henning Brian Rosen wrote: > What I don't think would work would be a service that got (filtered) > notifications of current location changes, and for each of those > notifications, queried LoST to determine the service notifier, and when it > changed, initiated a new subscription to the new notifier. > > Take an example: you are on a mobile device, near a border, and moving. > When you first start, you are in one country, and you subscribe to that > country's notification service. No problem. But, you are moving. Some > service is subscribed to your presence and tracking you (opt-in of course). > Does that service have to continuously query using LoST to determine that > you have crossed the boundary? > > Brian > > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com] > Sent: Wednesday, March 22, 2006 11:31 AM > To: br@brianrosen.net > Cc: 'Andrew Newton'; 'Henning Schulzrinne'; ecrit@ietf.org > Subject: Re: [Ecrit] Thought on citizen notification & LoST > > > Hi Brian; > > I think Rohan was suggesting some draft for filtering location info > and event package for delivering location for the purpose of "I > want to know where foo is.". I guess one can use the information > attained through the event package mentioned above and plug > that into what henning is suggesting. > > Regards > Shida > > Brian Rosen wrote: >> Generally, I think this is a good idea. >> >> A problem with it is that what you REALLY want is an opt-in of the form >> "send me notices of emergencies where I am at the moment," which is fairly >> straightforward, but you also want one that was "send me notices of >> emergencies where my child is at the moment", which is less > straightforward. >> >> The general way notification services that exist now work is that you >> register with an AREA of interest, and a notifier registers with an area > of >> service. For example, Contra Costa County Sheriffs Office registers as a >> recipient of weather events within Contra Costa County. NOAA registers as > a >> notifier of weather events for all of the United States. If NOAA issues > an >> alert for four counties including Contra Costa County; the Sheriffs office >> gets that alert. Look at EPAD at Comcare (www.comcare.org/epad.html). >> >> Nevertheless, Henning has talked about keeping "liveness" of a mapping by >> tracking location relative to the service boundary of, say, a PSAP. I'm >> still not sure how that works, but if it did, it would be the kind of > thing >> we want for this use. >> >> Brian >> >> >> ________________________________________ >> From: Andrew Newton [mailto:andy@hxr.us] >> Sent: Wednesday, March 22, 2006 10:42 AM >> To: Henning Schulzrinne >> Cc: 'ecrit@ietf.org' >> Subject: Re: [Ecrit] Thought on citizen notification & LoST >> >> >> On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: >> >> >> This is not in scope, but it might be worth keeping in mind, particularly >> since it seems to fit the existing model. (We'd probably define a new >> service URN service for that.) >> >> I was thinking exactly that. urn:service.sos.disaster-notice. And defining >> it in such a way, I think it might be within the scope of the working > group. >> -andy >> >> >> _______________________________________________ >> 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 Wed Mar 22 12:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM77x-000679-El; Wed, 22 Mar 2006 12:28:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM77w-000674-O5 for ecrit@ietf.org; Wed, 22 Mar 2006 12:28:08 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM77v-0000dv-As for ecrit@ietf.org; Wed, 22 Mar 2006 12:28:08 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 22 Mar 2006 09:28:05 -0800 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: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 09:28:04 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750488DC2C@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Dial Strings... Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAfhPA= From: "Roger Marshall" To: "Stastny Richard" , "Marc Linsner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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: , Errors-To: ecrit-bounces@ietf.org I think this does solve the problem of a nomadic or mobile UA getting the appropriate dial string. The requirement could be that, upon boot, the UA launches various flagged LoST request(s): E.G. something like, "-v", to request validation of a given location, "-u", for PSAP uri "-d", for dialstring (whether home or visited) This would cut down on extra information not being always wanted/needed. I agree with Marc, that this ability should be made to be turned ON|OFF, based on whether a UA provider/service provider wants to deploy hardcoded values for static use case deployments. Roger Marshall.=20 >-----Original Message----- >From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 >Sent: Wednesday, March 22, 2006 9:30 AM >To: Marc Linsner; ecrit@ietf.org >Subject: RE: [Ecrit] Dial Strings... > >I consider this very useful, and >not much additional effort >=20 >It requires also on location infromation based on country It=20 >could be given back with the country default PSAP(s) if only=20 >the country is known >=20 >I think this was also in the original cc.sos.arpa proposal from Brian >=20 >The basic question is what happens if the local dialstring is=20 >clashing with other local numbers. THis may be left to the=20 >user client, but we should give some guidance here. >=20 >Richard > >________________________________ > >Von: Marc Linsner [mailto:mlinsner@cisco.com] >Gesendet: Mi 22.03.2006 18:12 >An: ecrit@ietf.org >Betreff: [Ecrit] Dial Strings... > > > >I want to float an idea wrt dial strings. > >We had some conversation for some time as to the value of the=20 >UA understanding local emergency dial strings. Since we're at=20 >the end of the requirements for LoST, please express opinion=20 >on whether distributing local dial strings via LoST is=20 >feasible and worthy of adding to our requirements draft. > >One example: UA boots --> UA launches LoST query and receives=20 >location validation, PSAP uri (for fallback), and local dial strings. > >Thanks, > >-Marc- > >_______________________________________________ >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 Wed Mar 22 12:29:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM79M-00077M-Ea; Wed, 22 Mar 2006 12:29:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM79K-00077H-BW for ecrit@ietf.org; Wed, 22 Mar 2006 12:29:34 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM79J-0000gl-5a for ecrit@ietf.org; Wed, 22 Mar 2006 12:29:34 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MHTTcL007946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 12:29:30 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MHTTx6016196; Wed, 22 Mar 2006 12:29:29 -0500 Message-ID: <4421897A.9010607@cs.columbia.edu> Date: Wed, 22 Mar 2006 12:29:30 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Dial Strings... References: <004e01c64dd5$44654c60$e07060cc@amer.cisco.com> In-Reply-To: <004e01c64dd5$44654c60$e07060cc@amer.cisco.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, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: , Errors-To: ecrit-bounces@ietf.org Certainly. I prefer a slightly more dynamic solution since dial strings do change in some jurisdictions, particularly as countries converge towards 112, for example. Also, as devices are passed around, inherited and sold, I'd rather not rely on the configuration choices of the previous owner. Also, in some cases, users may actually have difficulty remembering the right number, particularly for some of the more obscure services such as mountain rescue. I always had difficulty in Germany remembering whether 110 was police and 112 was fire or the other way around. Marc Linsner wrote: > Home dials strings *could* also be user-input-to-new-phone hardcoded. > > -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 12:29:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM79W-00079B-QA; Wed, 22 Mar 2006 12:29:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM79V-000796-Ud for ecrit@ietf.org; Wed, 22 Mar 2006 12:29:45 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM79U-0000hG-HB for ecrit@ietf.org; Wed, 22 Mar 2006 12:29:45 -0500 Received: from dhcp-wireless-134-205.ietf65.org ([130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FM79O-0001Gl-2H; Wed, 22 Mar 2006 11:29:38 -0600 Message-ID: <4421897E.3030206@ntt-at.com> Date: Wed, 22 Mar 2006 09:29:34 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Thought on citizen notification & LoST References: <033701c64dcf$9cf15af0$73818182@cis.neustar.com> <4421858D.1050600@cs.columbia.edu> In-Reply-To: <4421858D.1050600@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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: , Errors-To: ecrit-bounces@ietf.org I guess other alternative is to enable people to subscribe to user's emergency notification. This way, only target user will be the one needing to query the LoST. 1. I would subscribe to my son's emergency notification info. 2. When my son's UA or PUA receives an emergency notification from emergency notification server it sends out the same information to the subscriber who subscribed to emergency notification info. BTW I am concerned with frequency the LoST queries are to be made if the service discussed here is really considered. To really minimize the frequency of the queries, the only way I can think of is by setting a query trigger filter based on location range on the user device or out-bound proxy(In which case proxy needs to store the location used in the last query for comparison). Regards Shida Schubert Henning Schulzrinne wrote: > You seem to have a mediated model in mind where the end user > subscribes to the 'emergency alerting service' and the mediator then > provides and possibly aggregates alerts from multiple sources. The > mediator obviously needs to subscribe to my location to make this > work, like you indicate. > > In that model, the mediating service would get the location > notifications for you (and probably lots of other people), query LoST > and cache the results. If somebody shows up in a new area, it changes > the alert notification or the alert subscriptions. This certainly > doesn't require re-querying LoST for each border crossing. > > Henning > > Brian Rosen wrote: >> What I don't think would work would be a service that got (filtered) >> notifications of current location changes, and for each of those >> notifications, queried LoST to determine the service notifier, and >> when it >> changed, initiated a new subscription to the new notifier. >> >> Take an example: you are on a mobile device, near a border, and moving. >> When you first start, you are in one country, and you subscribe to that >> country's notification service. No problem. But, you are moving. >> Some >> service is subscribed to your presence and tracking you (opt-in of >> course). >> Does that service have to continuously query using LoST to determine >> that >> you have crossed the boundary? >> Brian >> >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, March >> 22, 2006 11:31 AM >> To: br@brianrosen.net >> Cc: 'Andrew Newton'; 'Henning Schulzrinne'; ecrit@ietf.org >> Subject: Re: [Ecrit] Thought on citizen notification & LoST >> >> >> Hi Brian; >> >> I think Rohan was suggesting some draft for filtering location info >> and event package for delivering location for the purpose of "I >> want to know where foo is.". I guess one can use the information >> attained through the event package mentioned above and plug >> that into what henning is suggesting. >> >> Regards >> Shida >> >> Brian Rosen wrote: >>> Generally, I think this is a good idea. >>> >>> A problem with it is that what you REALLY want is an opt-in of the form >>> "send me notices of emergencies where I am at the moment," which is >>> fairly >>> straightforward, but you also want one that was "send me notices of >>> emergencies where my child is at the moment", which is less >> straightforward. >>> >>> The general way notification services that exist now work is that you >>> register with an AREA of interest, and a notifier registers with an >>> area >> of >>> service. For example, Contra Costa County Sheriffs Office registers >>> as a >>> recipient of weather events within Contra Costa County. NOAA >>> registers as >> a >>> notifier of weather events for all of the United States. If NOAA >>> issues >> an >>> alert for four counties including Contra Costa County; the Sheriffs >>> office >>> gets that alert. Look at EPAD at Comcare (www.comcare.org/epad.html). >>> >>> Nevertheless, Henning has talked about keeping "liveness" of a >>> mapping by >>> tracking location relative to the service boundary of, say, a PSAP. >>> I'm >>> still not sure how that works, but if it did, it would be the kind of >> thing >>> we want for this use. >>> >>> Brian >>> >>> >>> ________________________________________ >>> From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, March 22, >>> 2006 10:42 AM >>> To: Henning Schulzrinne >>> Cc: 'ecrit@ietf.org' >>> Subject: Re: [Ecrit] Thought on citizen notification & LoST >>> >>> >>> On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: >>> >>> >>> This is not in scope, but it might be worth keeping in mind, >>> particularly >>> since it seems to fit the existing model. (We'd probably define a new >>> service URN service for that.) >>> >>> I was thinking exactly that. urn:service.sos.disaster-notice. And >>> defining >>> it in such a way, I think it might be within the scope of the working >> group. >>> -andy >>> >>> >>> _______________________________________________ >>> 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 Wed Mar 22 12:32:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7C0-00017k-JQ; Wed, 22 Mar 2006 12:32:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7Bz-00014W-Q8 for ecrit@ietf.org; Wed, 22 Mar 2006 12:32:19 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7By-0000mv-G4 for ecrit@ietf.org; Wed, 22 Mar 2006 12:32:19 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM7Bp-000166-Ov; Wed, 22 Mar 2006 11:32:10 -0600 From: "Brian Rosen" To: "'Stastny Richard'" , "'Marc Linsner'" , Subject: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 12:32:11 -0500 Message-ID: <037d01c64dd6$8f9bcb90$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeA= In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C491E@oefeg-s04.oefeg.loc> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org The intersection of a local emergency dialstring with a home dialplan are ugly. We looked at this in PacketCable 2.0 work. I believe the conclusion is that with any of the methods people have for representing dialplans that can be automatically processed by a phone or proxy, that inserting the local dialstring into those dialplans is way too hard. What you probably have to do is to just have a list of local dialstrings and have the interpreter have special processing that looks for them independently of the dial plan interpretation. The home dial string can be imbedded in the dial plan, and almost always is. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, March 22, 2006 12:30 PM To: Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... I consider this very useful, and not much additional effort It requires also on location infromation based on country It could be given back with the country default PSAP(s) if only the country is known I think this was also in the original cc.sos.arpa proposal from Brian The basic question is what happens if the local dialstring is clashing with other local numbers. THis may be left to the user client, but we should give some guidance here. Richard ________________________________ Von: Marc Linsner [mailto:mlinsner@cisco.com] Gesendet: Mi 22.03.2006 18:12 An: ecrit@ietf.org Betreff: [Ecrit] Dial Strings... I want to float an idea wrt dial strings. We had some conversation for some time as to the value of the UA understanding local emergency dial strings. Since we're at the end of the requirements for LoST, please express opinion on whether distributing local dial strings via LoST is feasible and worthy of adding to our requirements draft. One example: UA boots --> UA launches LoST query and receives location validation, PSAP uri (for fallback), and local dial strings. Thanks, -Marc- _______________________________________________ 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 Wed Mar 22 12:36:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7Fg-0003QR-8f; Wed, 22 Mar 2006 12:36:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7Fe-0003Q7-R1 for ecrit@ietf.org; Wed, 22 Mar 2006 12:36:06 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7Fd-0000wC-JX for ecrit@ietf.org; Wed, 22 Mar 2006 12:36:06 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MHa1cL009346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 12:36:02 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MHa0Hk016204; Wed, 22 Mar 2006 12:36:00 -0500 Message-ID: <44218B00.20302@cs.columbia.edu> Date: Wed, 22 Mar 2006 12:36:00 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Thought on citizen notification & LoST References: <037c01c64dd5$f7cc6c20$73818182@cis.neustar.com> In-Reply-To: <037c01c64dd5$f7cc6c20$73818182@cis.neustar.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, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: , Errors-To: ecrit-bounces@ietf.org I think we're in general agreement. I would add that a service provider can choose to approximate the coverage region by a fewer-faced polygon, at the cost of having overlapping polygons in the border regions. This is probably harmless in practice and may even be useful since emergencies rarely conform to county boundaries. Brian Rosen wrote: > I think you more or less answered the question earlier, when you described > how LoST can return information that lets you determine locally if you are > still in an area where the mapping remains valid. I'm still somewhat > skeptical of how that works for geo (I'm guessing you have to return the > entire service boundary of the service, which could be pretty large, and > then the local decision is point-in-polygon). It's very nice where there > are regular civic boundaries (for example, valid for the entire > country/state/county...), which probably would be common. > > Brian > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 12:49:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7T2-0003gC-DS; Wed, 22 Mar 2006 12:49:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7T0-0003g7-HS for ecrit@ietf.org; Wed, 22 Mar 2006 12:49:54 -0500 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7T0-0001Nz-7R for ecrit@ietf.org; Wed, 22 Mar 2006 12:49:54 -0500 Received: from zcarhxm1.corp.nortel.com (zcarhxm1.corp.nortel.com [47.129.230.97]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2MHnfX28845 for ; Wed, 22 Mar 2006 12:49:41 -0500 (EST) 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: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 12:49:22 -0500 Message-ID: <9671A92C3C8B5744BC97F855F7CB646509030B82@zcarhxm1.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Dial Strings... Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAF5XAA== From: "Perry Prozeniuk" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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: , Errors-To: ecrit-bounces@ietf.org The result, even with the special processing approach is that some numbers may change meaning if overridden with local emergency dial strings. The user may not be aware of this occurring and being unfamiliar with the local emergency dial strings make accidental calls to emergency services and won't be able to reach the service they wanted. As Brian indicated, this is a very ugly area due to the variation in dial plans and local emergency dial strings (enterprise networks with their own dial plans can make it even worse). Perry Prozeniuk -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Wednesday, March 22, 2006 12:32 PM To: 'Stastny Richard'; 'Marc Linsner'; ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... The intersection of a local emergency dialstring with a home dialplan are ugly. We looked at this in PacketCable 2.0 work. I believe the conclusion is that with any of the methods people have for representing dialplans that can be automatically processed by a phone or proxy, that inserting the local dialstring into those dialplans is way too hard. What you probably have to do is to just have a list of local dialstrings and have the interpreter have special processing that looks for them independently of the dial plan interpretation. The home dial string can be imbedded in the dial plan, and almost always is. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 Sent: Wednesday, March 22, 2006 12:30 PM To: Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... I consider this very useful, and not much additional effort =20 It requires also on location infromation based on country It could be given back with the country default PSAP(s) if only the country is known =20 I think this was also in the original cc.sos.arpa proposal from Brian =20 The basic question is what happens if the local dialstring is clashing with other local numbers. THis may be left to the user client, but we should give some guidance here. =20 Richard ________________________________ Von: Marc Linsner [mailto:mlinsner@cisco.com] Gesendet: Mi 22.03.2006 18:12 An: ecrit@ietf.org Betreff: [Ecrit] Dial Strings... I want to float an idea wrt dial strings. We had some conversation for some time as to the value of the UA understanding local emergency dial strings. Since we're at the end of the requirements for LoST, please express opinion on whether distributing local dial strings via LoST is feasible and worthy of adding to our requirements draft. One example: UA boots --> UA launches LoST query and receives location validation, PSAP uri (for fallback), and local dial strings. Thanks, -Marc- _______________________________________________ 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 Wed Mar 22 13:01:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7eQ-00043K-OM; Wed, 22 Mar 2006 13:01:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7eP-00043C-Ou for ecrit@ietf.org; Wed, 22 Mar 2006 13:01:41 -0500 Received: from aismt08p.bellsouth.com ([139.76.165.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7eO-0001u6-Dv for ecrit@ietf.org; Wed, 22 Mar 2006 13:01:41 -0500 Received: from ([90.152.52.46]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.121855775; Wed, 22 Mar 2006 13:00:35 -0500 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01al10015010118.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 22 Mar 2006 12:00:01 -0600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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] Dial Strings... Date: Wed, 22 Mar 2006 11:57:05 -0600 Message-ID: <9888E1AA13C3A1459D122996A58C0E11036FD097@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Dial Strings... Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAMS4IA== From: "Stark, Barbara" To: , "Stastny Richard" , "Marc Linsner" , X-OriginalArrivalTime: 22 Mar 2006 18:00:01.0390 (UTC) FILETIME=[7098A8E0:01C64DDA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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: , Errors-To: ecrit-bounces@ietf.org Brian said: The intersection of a local emergency dialstring with a home dialplan are ugly. We looked at this in PacketCable 2.0 work. I believe the conclusion is that with any of the methods people have for representing dialplans that can be automatically processed by a phone or proxy, that inserting the local dialstring into those dialplans is way too hard. What you probably have to do is to just have a list of local dialstrings and have the interpreter have special processing that looks for them independently of the dial plan interpretation. The home dial string can be imbedded in the dial plan, and almost always is. -------- Thanks, Brian. That's exactly what I wanted to say. If we do want to design methods to get the visited emergency strings (can we use the words "visited" and "home" -- "local" is really confusing to me, since I'm not sure if it's local to home or local to visited?), I believe we also need to provide guidance on how to use these strings, relative to the device's current digit map. I think predictable behavior on the part of client devices is very important here.=20 Barbara ***** "The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination = or other use of, or taking of any action in reliance upon, this = information by persons or entities other than the intended recipient is = prohibited. If you received this in error, please contact the sender = and delete the material from all computers." 118 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 13:12:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7ok-0002zl-Ef; Wed, 22 Mar 2006 13:12:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM7oi-0002z0-QC for ecrit@ietf.org; Wed, 22 Mar 2006 13:12:20 -0500 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM7oh-0002X1-Cl for ecrit@ietf.org; Wed, 22 Mar 2006 13:12:20 -0500 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1FXN0o-0000DW-00; Sat, 22 Apr 2006 14:39:18 -0400 From: "Francois D. Menard" To: , "'Stastny Richard'" , "'Marc Linsner'" , Subject: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 13:12:02 -0500 Message-ID: <009601c64ddc$2b39f400$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAATanQA== In-Reply-To: <037d01c64dd6$8f9bcb90$73818182@cis.neustar.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 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: , Errors-To: ecrit-bounces@ietf.org Brian Rosen wrote: > The intersection of a local emergency dialstring with a home dialplan = are ugly. =20 At home, I have a Mediatrix 2102 (http://www.mediatrix.com/products_devices.php?prodid=3D14) with 911 = fallback (US Patent 6,944,151) hooked to an Asterisk box and the digit map inside = the 2102 recognizes 911 as a priority number sequence and falls backs on my = POTS line. Asterisk has therefore no knowledge of 911 in its dial plan. This works very well. If the call is to go over VoIP instead of over POTS, = then the 2102 would send a SIP SOS and I would pray for the CMTS to knock off = my neighbors pumping P2P upstream so as to ensure I have priority over them talking to the PSAP. Unfortunately, the CMTS providing service to my = home, even if my ISP interconnects directly to it, has no ability to do this = as part of the wholesale service provided by that cable company to my ISP. = This is why I keep a POTS line at home. I asked the CRTC to force the ILECs = to sell 911-only POTS for $5 per month but the CRTC asked that I file a = formal complaint. Cheers! -=3DFrancois=3D- -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 22 mars 2006 12:32 To: 'Stastny Richard'; 'Marc Linsner'; ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... The intersection of a local emergency dialstring with a home dialplan = are ugly. We looked at this in PacketCable 2.0 work. I believe the = conclusion is that with any of the methods people have for representing dialplans = that can be automatically processed by a phone or proxy, that inserting the = local dialstring into those dialplans is way too hard. What you probably have = to do is to just have a list of local dialstrings and have the interpreter = have special processing that looks for them independently of the dial plan interpretation. The home dial string can be imbedded in the dial plan, and almost always = is. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, March 22, 2006 12:30 PM To: Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... I consider this very useful, and not much additional effort =20 It requires also on location infromation based on country It could be = given back with the country default PSAP(s) if only the country is known =20 I think this was also in the original cc.sos.arpa proposal from Brian =20 The basic question is what happens if the local dialstring is clashing = with other local numbers. THis may be left to the user client, but we should = give some guidance here. =20 Richard ________________________________ Von: Marc Linsner [mailto:mlinsner@cisco.com] Gesendet: Mi 22.03.2006 18:12 An: ecrit@ietf.org Betreff: [Ecrit] Dial Strings... I want to float an idea wrt dial strings. We had some conversation for some time as to the value of the UA understanding local emergency dial strings. Since we're at the end of = the requirements for LoST, please express opinion on whether distributing = local dial strings via LoST is feasible and worthy of adding to our = requirements draft. One example: UA boots --> UA launches LoST query and receives location validation, PSAP uri (for fallback), and local dial strings. Thanks, -Marc- _______________________________________________ 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 Wed Mar 22 13:27:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM837-0003lt-Bh; Wed, 22 Mar 2006 13:27:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM835-0003e9-LN for ecrit@ietf.org; Wed, 22 Mar 2006 13:27:11 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM833-0003lN-Aq for ecrit@ietf.org; Wed, 22 Mar 2006 13:27:11 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 22 Mar 2006 10:27:08 -0800 X-IronPort-AV: i="4.03,119,1141632000"; d="scan'208"; a="263533263:sNHT66067290" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k2MIR81j013360; Wed, 22 Mar 2006 10:27:08 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 10:27:08 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 10:27:08 -0800 From: "Marc Linsner" To: "'Stark, Barbara'" , Subject: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 13:27:07 -0500 Message-ID: <001901c64dde$3a357c20$6059150a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAMS4IAAArxbA In-Reply-To: <9888E1AA13C3A1459D122996A58C0E11036FD097@bre2k61p-55> X-OriginalArrivalTime: 22 Mar 2006 18:27:08.0143 (UTC) FILETIME=[3A3777F0:01C64DDE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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: , Errors-To: ecrit-bounces@ietf.org Barbara, First, I'm not opposed to using the terms you suggested. But I would like to provide some rationale. The term "local" is a currency issue. "Local" is where I'm at right now. The term "visited" has less meaning in the Internet model since from the application point of view, the Internet is your "home" network (there is only one Internet). The term "home" doesn't refer to a network per se, but locale that the user is most oriented to the local custom(s) (dial 9-1-1 as example in North America). -Marc- > -----Original Message----- > From: Stark, Barbara [mailto:Barbara.Stark@bellsouth.com] > Sent: Wednesday, March 22, 2006 12:57 PM > To: br@brianrosen.net; Stastny Richard; Marc Linsner; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > Brian said: > The intersection of a local emergency dialstring with a home > dialplan are ugly. We looked at this in PacketCable 2.0 > work. I believe the conclusion is that with any of the > methods people have for representing dialplans that can be > automatically processed by a phone or proxy, that inserting > the local dialstring into those dialplans is way too hard. > What you probably have to do is to just have a list of local > dialstrings and have the interpreter have special processing > that looks for them independently of the dial plan interpretation. > > The home dial string can be imbedded in the dial plan, and > almost always is. > > -------- > Thanks, Brian. That's exactly what I wanted to say. If we do > want to design methods to get the visited emergency strings > (can we use the words "visited" and "home" -- "local" is > really confusing to me, since I'm not sure if it's local to > home or local to visited?), I believe we also need to provide > guidance on how to use these strings, relative to the > device's current digit map. I think predictable behavior on > the part of client devices is very important here. > Barbara > > ***** > "The information transmitted is intended only for the person > or entity to which it is addressed and may contain > confidential, proprietary, and/or privileged material. Any > review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by > persons or entities other than the intended recipient is > prohibited. If you received this in error, please contact > the sender and delete the material from all computers." 118 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 14:06:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8ej-0005nt-Dy; Wed, 22 Mar 2006 14:06:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM8ei-0005jq-BF for ecrit@ietf.org; Wed, 22 Mar 2006 14:06:04 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM8ef-0005fQ-W0 for ecrit@ietf.org; Wed, 22 Mar 2006 14:06:04 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM8eX-0002AH-NZ; Wed, 22 Mar 2006 13:05:53 -0600 From: "Brian Rosen" To: "'Perry Prozeniuk'" , Subject: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 14:05:55 -0500 Message-ID: <03a101c64de3$a78c1bd0$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAF5XAAACwtCQ In-Reply-To: <9671A92C3C8B5744BC97F855F7CB646509030B82@zcarhxm1.corp.nortel.com> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We've looked over the issue of Do you HAVE to support the local/visited dialstring Should you support the local dialstring Do you HAVE to support the home dialstring Should you support the home dialstring The result is 1. There are regulations in most countries that REQUIRE you to support the local dialstring 2. There are no requirements to support the home dialstring 3. Nearly everyone thinks it would be good to support the home dialstring 4. Opinions on whether you should support the local dialstring are mixed. Some think it screws up the dialplan so much it shouldn't be done Of course, #1 above rules. So, #4 doesn't matter; you MUST support the local/visited dialstring. There is a lot of support for #3, so I think we MUST have a mechanism to support both home and local/visited dialstrings. Use of local/visited is a MUST. Use of home is a MAY. Brian -----Original Message----- From: Perry Prozeniuk [mailto:perrylp@nortel.com] Sent: Wednesday, March 22, 2006 12:49 PM To: ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... The result, even with the special processing approach is that some numbers may change meaning if overridden with local emergency dial strings. The user may not be aware of this occurring and being unfamiliar with the local emergency dial strings make accidental calls to emergency services and won't be able to reach the service they wanted. As Brian indicated, this is a very ugly area due to the variation in dial plans and local emergency dial strings (enterprise networks with their own dial plans can make it even worse). Perry Prozeniuk -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Wednesday, March 22, 2006 12:32 PM To: 'Stastny Richard'; 'Marc Linsner'; ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... The intersection of a local emergency dialstring with a home dialplan are ugly. We looked at this in PacketCable 2.0 work. I believe the conclusion is that with any of the methods people have for representing dialplans that can be automatically processed by a phone or proxy, that inserting the local dialstring into those dialplans is way too hard. What you probably have to do is to just have a list of local dialstrings and have the interpreter have special processing that looks for them independently of the dial plan interpretation. The home dial string can be imbedded in the dial plan, and almost always is. Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, March 22, 2006 12:30 PM To: Marc Linsner; ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... I consider this very useful, and not much additional effort It requires also on location infromation based on country It could be given back with the country default PSAP(s) if only the country is known I think this was also in the original cc.sos.arpa proposal from Brian The basic question is what happens if the local dialstring is clashing with other local numbers. THis may be left to the user client, but we should give some guidance here. Richard ________________________________ Von: Marc Linsner [mailto:mlinsner@cisco.com] Gesendet: Mi 22.03.2006 18:12 An: ecrit@ietf.org Betreff: [Ecrit] Dial Strings... I want to float an idea wrt dial strings. We had some conversation for some time as to the value of the UA understanding local emergency dial strings. Since we're at the end of the requirements for LoST, please express opinion on whether distributing local dial strings via LoST is feasible and worthy of adding to our requirements draft. One example: UA boots --> UA launches LoST query and receives location validation, PSAP uri (for fallback), and local dial strings. Thanks, -Marc- _______________________________________________ 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 14:28:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM901-0001EA-Fz; Wed, 22 Mar 2006 14:28:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM900-0001E5-J9 for ecrit@ietf.org; Wed, 22 Mar 2006 14:28:04 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM8zz-0006Nv-50 for ecrit@ietf.org; Wed, 22 Mar 2006 14:28:04 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Wed, 22 Mar 2006 11:28:01 -0800 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: RE: [Ecrit] ECRIT Working Group Session: Summary Date: Wed, 22 Mar 2006 11:28:00 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A65750488DE32@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ECRIT Working Group Session: Summary Thread-Index: AcZN0Ro8SnAVOeZ1SHObJavIWfPL6wAFGuaw From: "Roger Marshall" To: "Hannes Tschofenig" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: , Errors-To: ecrit-bounces@ietf.org Hannes: Also, as agreed (w/Tom), I will post to the issue tracker, newly proposed text which outlines a client-to-server identification/authentication requirement, targeted for proxy-based client mapping use cases. Roger. >-----Original Message----- >From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 >Sent: Wednesday, March 22, 2006 8:52 AM >To: ecrit@ietf.org >Subject: [Ecrit] ECRIT Working Group Session: Summary > >Hi all, > >at the ECRIT WG meeting yesterday we discussed a few aspects=20 >and we would like to confirm them on the mailing list: > > >* Requirements >************** > =20 >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requiremen >ts-06.txt > >Issues raised during WGLC will be added to the issue tracker, will be=20 >discussed and a new draft version will be resubmitted very soon. > >Roger will discuss the align the usage of RFC 2119 language in the=20 >Security Threats draft and the Requirements draft. > > >* Security Threats >****************** > >http://www.ietf.org/internet-drafts/draft-taylor-ecrit-security >-threats-03.txt > >Tom will reflect comments regarding the security aspects of a proxy=20 >initiating the mapping protocol interaction. Text might need to go to=20 >the requirements document as well. > > >* A Uniform Resource Name for Services >************************************** > >http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-01.txt > >Based on long discussions during the meeting Henning will send=20 >a summary=20 >of the call identification with a suggested approach on resolving the=20 >issue. Discussions during the meeting already pointed to a preferred=20 >approach but more discussions might be needed. > >Text about DDDS resolution will be removed from the draft and moved to=20 >the LoST document. > >According to our charter milestones the document has to be=20 >finished soon. > > >* LoST >****** >http://www.ietf-ecrit.org/cache/draft-hardie-ecrit-lost-00.txt > >The participants showed interest to make LoST a working group item and=20 >to work on it aggressively. > > >* Mapping Architecture and Framework >************************************ > >http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-map >ping-arch-00.txt > >The working group expressed interest in working on such a document.=20 >Since this work is not captured by the current charter the chairs will=20 >compile a proposal for a modified charter. > > >* ECRIT Big Picture >******************* > >There was interest in the past to write a document that=20 >explains the big=20 >picture. The chairs will form a design team to work on such a document. > > >* Phone BCP >*********** > >http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-00.txt > >The working group expressed interest in working on such a document.=20 >Since this work is not captured by the current charter the chairs will=20 >compile a proposal for a modified charter. > > >*Analyzing ECRIT Mapping of a Location to an Emergency URI for=20 >Emergency=20 >Calling >*************************************************************** >********* > >http://www.ietf.org/internet-drafts/draft-polk-ecrit-mapping-ev >ents-00.txt > >This document will be discussed further on the mailing list. > > >* Authority To Citizen Notification >*********************************** > >This presentation was purely informational for the working group. >Interested parties should contact the chairs and/or Steve Norreys. > > >* 3GPP Emergency Services and ECRIT work >**************************************** > >Discussions about 3GPP Emergency Service work revealed the need to=20 >establish a closer interaction between ECRIT and the respective 3GPP=20 >groups. The chairs will think about a possible way forward. > > >Please let us know if you have further comments. > >Ciao >Hannes > > >_______________________________________________ >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 Wed Mar 22 14:37:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM98u-0001nG-7M; Wed, 22 Mar 2006 14:37:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM98s-0001jy-6T for ecrit@ietf.org; Wed, 22 Mar 2006 14:37:14 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM98q-0006mX-To for ecrit@ietf.org; Wed, 22 Mar 2006 14:37:14 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MJatcL009251 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 14:36:55 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MJaXYZ016574; Wed, 22 Mar 2006 14:36:34 -0500 Message-ID: <4421A743.9000004@cs.columbia.edu> Date: Wed, 22 Mar 2006 14:36:35 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: br@brianrosen.net Subject: Re: [Ecrit] Dial Strings... References: <037d01c64dd6$8f9bcb90$73818182@cis.neustar.com> In-Reply-To: <037d01c64dd6$8f9bcb90$73818182@cis.neustar.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Cc: 'Stastny Richard' , 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: , Errors-To: ecrit-bounces@ietf.org We have gone over this issue a few times in the past. A short summary to prevent yet more of revisiting: The issue of home vs. visited/local dial strings affects mostly mobile devices. This is not a major concern for desk phones in offices. Local (PBX-style) dial plans are not an issue for residential users. All mobile devices of interest use en bloc dialing ("Send" key), removing many of the dial plan collisions. Thus, to make this problem tractable, can we state precisely the combination of circumstances where this is an issue? I see three scenarios: - Enterprise: probably can configure emergency dial strings manually since this is a managed environment. I trust a sysadmin to spend enough time getting it right. - Residential (DSL/cable): generally, not mobile, but may have overlap dialing. Doesn't have local dial extensions and such. Insertion into dial plan should be easy. - Mobile (3G): no overlap dialing; mostly, no local dial plans (extensions). Needs both home and visited. Danger is mainly overlap with other service numbers. Henning Brian Rosen wrote: > The intersection of a local emergency dialstring with a home dialplan are > ugly. We looked at this in PacketCable 2.0 work. I believe the conclusion > is that with any of the methods people have for representing dialplans that > can be automatically processed by a phone or proxy, that inserting the local > dialstring into those dialplans is way too hard. What you probably have to > do is to just have a list of local dialstrings and have the interpreter have > special processing that looks for them independently of the dial plan > interpretation. > > The home dial string can be imbedded in the dial plan, and almost always is. > > Brian > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 22, 2006 12:30 PM > To: Marc Linsner; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > I consider this very useful, and > not much additional effort > > It requires also on location infromation based on country > It could be given back with the country default PSAP(s) > if only the country is known > > I think this was also in the original cc.sos.arpa proposal from Brian > > The basic question is what happens if the local dialstring is > clashing with other local numbers. THis may be left to the user > client, but we should give some guidance here. > > Richard > > ________________________________ > > Von: Marc Linsner [mailto:mlinsner@cisco.com] > Gesendet: Mi 22.03.2006 18:12 > An: ecrit@ietf.org > Betreff: [Ecrit] Dial Strings... > > > > I want to float an idea wrt dial strings. > > We had some conversation for some time as to the value of the UA > understanding local emergency dial strings. Since we're at the end of the > requirements for LoST, please express opinion on whether distributing local > dial strings via LoST is feasible and worthy of adding to our requirements > draft. > > One example: UA boots --> UA launches LoST query and receives location > validation, PSAP uri (for fallback), and local dial strings. > > Thanks, > > -Marc- > > _______________________________________________ > 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 Wed Mar 22 14:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9NU-0004WZ-5a; Wed, 22 Mar 2006 14:52:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9NT-0004WU-3B for ecrit@ietf.org; Wed, 22 Mar 2006 14:52:19 -0500 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9NS-0007UE-NF for ecrit@ietf.org; Wed, 22 Mar 2006 14:52:19 -0500 Received: from [130.129.130.179] ([::ffff:130.129.130.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 22 Mar 2006 14:51:25 -0500 id 01588172.4421AABD.0000175A In-Reply-To: <4421A743.9000004@cs.columbia.edu> References: <037d01c64dd6$8f9bcb90$73818182@cis.neustar.com> <4421A743.9000004@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7FA8AD83-F03C-4E33-84FB-ADC9F192933B@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 14:52:15 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: 'Stastny Richard' , 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: , Errors-To: ecrit-bounces@ietf.org Henning, I agree that we should break this down into scenarios to understand the requirements. However, your residential case needs adjustment. There exist today VSPs who allow their customers to take their UAs out of their homes and plug them into other access networks, for instance at a relatives house or in a hotel. -andy On Mar 22, 2006, at 2:36 PM, Henning Schulzrinne wrote: > We have gone over this issue a few times in the past. A short > summary to prevent yet more of revisiting: > > The issue of home vs. visited/local dial strings affects mostly > mobile devices. This is not a major concern for desk phones in > offices. Local (PBX-style) dial plans are not an issue for > residential users. All mobile devices of interest use en bloc > dialing ("Send" key), removing many of the dial plan collisions. > > Thus, to make this problem tractable, can we state precisely the > combination of circumstances where this is an issue? I see three > scenarios: > > - Enterprise: probably can configure emergency dial strings > manually since this is a managed environment. I trust a sysadmin to > spend enough time getting it right. > > - Residential (DSL/cable): generally, not mobile, but may have > overlap dialing. Doesn't have local dial extensions and such. > Insertion into dial plan should be easy. > > - Mobile (3G): no overlap dialing; mostly, no local dial plans > (extensions). Needs both home and visited. Danger is mainly overlap > with other service numbers. > > Henning > > Brian Rosen wrote: >> The intersection of a local emergency dialstring with a home >> dialplan are >> ugly. We looked at this in PacketCable 2.0 work. I believe the >> conclusion >> is that with any of the methods people have for representing >> dialplans that >> can be automatically processed by a phone or proxy, that inserting >> the local >> dialstring into those dialplans is way too hard. What you >> probably have to >> do is to just have a list of local dialstrings and have the >> interpreter have >> special processing that looks for them independently of the dial plan >> interpretation. >> The home dial string can be imbedded in the dial plan, and almost >> always is. >> Brian >> -----Original Message----- >> From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: >> Wednesday, March 22, 2006 12:30 PM >> To: Marc Linsner; ecrit@ietf.org >> Subject: RE: [Ecrit] Dial Strings... >> I consider this very useful, and >> not much additional effort >> It requires also on location infromation based on country >> It could be given back with the country default PSAP(s) >> if only the country is known >> I think this was also in the original cc.sos.arpa proposal from >> Brian >> The basic question is what happens if the local dialstring is >> clashing with other local numbers. THis may be left to the user >> client, but we should give some guidance here. >> Richard >> ________________________________ >> Von: Marc Linsner [mailto:mlinsner@cisco.com] >> Gesendet: Mi 22.03.2006 18:12 >> An: ecrit@ietf.org >> Betreff: [Ecrit] Dial Strings... >> I want to float an idea wrt dial strings. >> We had some conversation for some time as to the value of the UA >> understanding local emergency dial strings. Since we're at the >> end of the >> requirements for LoST, please express opinion on whether >> distributing local >> dial strings via LoST is feasible and worthy of adding to our >> requirements >> draft. >> One example: UA boots --> UA launches LoST query and receives >> location >> validation, PSAP uri (for fallback), and local dial strings. >> Thanks, >> -Marc- >> _______________________________________________ >> 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 14:52:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9Nk-0004er-BE; Wed, 22 Mar 2006 14:52:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9Nj-0004el-KK for ecrit@ietf.org; Wed, 22 Mar 2006 14:52:35 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9Nj-0007UZ-7K for ecrit@ietf.org; Wed, 22 Mar 2006 14:52:35 -0500 Received: from ([90.152.53.183]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.122101042; Wed, 22 Mar 2006 14:52:10 -0500 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010163.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 22 Mar 2006 13:52:10 -0600 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 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] Dial Strings... Date: Wed, 22 Mar 2006 13:52:09 -0600 Message-ID: <9888E1AA13C3A1459D122996A58C0E1107CA3518@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Dial Strings... thread-index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAF5XAAACwtCQAAGQqDA= From: "Stark, Barbara" To: , X-OriginalArrivalTime: 22 Mar 2006 19:52:10.0237 (UTC) FILETIME=[1B4D3AD0:01C64DEA] X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 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: , Errors-To: ecrit-bounces@ietf.org I suspect it's very hard for a European country to tell US VoIP providers that they HAVE to support "local" emergency strings for anyone using the US VoIP service while in that European country. How does the European country regulate US VoIP providers and their services?=20 Barbara > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 2:06 PM > To: 'Perry Prozeniuk'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... >=20 >=20 > We've looked over the issue of=20 > Do you HAVE to support the local/visited dialstring > Should you support the local dialstring > Do you HAVE to support the home dialstring > Should you support the home dialstring >=20 > The result is > 1. There are regulations in most countries that REQUIRE you to > support the local dialstring > 2. There are no requirements to support the home dialstring > 3. Nearly everyone thinks it would be good to support the home > dialstring > 4. Opinions on whether you should support the local=20 > dialstring are > mixed. Some think it screws up the dialplan so much it=20 > shouldn't be done >=20 > Of course, #1 above rules. So, #4 doesn't matter; you MUST=20 > support the > local/visited dialstring. There is a lot of support for #3,=20 > so I think we > MUST have a mechanism to support both home and local/visited=20 > dialstrings. > Use of local/visited is a MUST. Use of home is a MAY. >=20 > Brian >=20 > -----Original Message----- > From: Perry Prozeniuk [mailto:perrylp@nortel.com]=20 > Sent: Wednesday, March 22, 2006 12:49 PM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... >=20 > The result, even with the special processing approach is that some > numbers may change meaning if overridden with local emergency dial > strings. The user may not be aware of this occurring and being > unfamiliar with the local emergency dial strings make accidental calls > to emergency services and won't be able to reach the service they > wanted. As Brian indicated, this is a very ugly area due to the > variation in dial plans and local emergency dial strings (enterprise > networks with their own dial plans can make it even worse). >=20 > Perry Prozeniuk >=20 >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Wednesday, March 22, 2006 12:32 PM > To: 'Stastny Richard'; 'Marc Linsner'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... >=20 >=20 > The intersection of a local emergency dialstring with a home dialplan > are ugly. We looked at this in PacketCable 2.0 work. I believe the > conclusion is that with any of the methods people have for=20 > representing > dialplans that can be automatically processed by a phone or=20 > proxy, that > inserting the local dialstring into those dialplans is way too hard. > What you probably have to do is to just have a list of local=20 > dialstrings > and have the interpreter have special processing that looks for them > independently of the dial plan interpretation. >=20 > The home dial string can be imbedded in the dial plan, and=20 > almost always > is. >=20 > Brian >=20 > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Sent: Wednesday, March 22, 2006 12:30 PM > To: Marc Linsner; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... >=20 > I consider this very useful, and > not much additional effort > =20 > It requires also on location infromation based on country > It could be given back with the country default PSAP(s) > if only the country is known > =20 > I think this was also in the original cc.sos.arpa proposal from Brian > =20 > The basic question is what happens if the local dialstring is clashing > with other local numbers. THis may be left to the user client, but we > should give some guidance here. > =20 > Richard >=20 > ________________________________ >=20 > Von: Marc Linsner [mailto:mlinsner@cisco.com] > Gesendet: Mi 22.03.2006 18:12 > An: ecrit@ietf.org > Betreff: [Ecrit] Dial Strings... >=20 >=20 >=20 > I want to float an idea wrt dial strings. >=20 > We had some conversation for some time as to the value of the UA > understanding local emergency dial strings. Since we're at the end of > the requirements for LoST, please express opinion on whether > distributing local dial strings via LoST is feasible and worthy of > adding to our requirements draft. >=20 > One example: UA boots --> UA launches LoST query and receives location > validation, PSAP uri (for fallback), and local dial strings. >=20 > Thanks, >=20 > -Marc- >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 163 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 15:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9aG-0004cZ-57; Wed, 22 Mar 2006 15:05:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9aF-0004bi-3h for ecrit@ietf.org; Wed, 22 Mar 2006 15:05:31 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9aE-00087B-MS for ecrit@ietf.org; Wed, 22 Mar 2006 15:05:31 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM9a6-0007uP-7w; Wed, 22 Mar 2006 14:05:22 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , Subject: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 15:05:24 -0500 Message-ID: <03ba01c64deb$f6d0cc10$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAF5XAAACwtCQAAGQqDAAAIJRMA== In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1107CA3518@bre2k61p-55> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Barbara I agree that it was tough for the U.S. to regulate Skype when it was Belgium based. As a practical matter, many carriers do obey the laws of the country where their users roam, if only because they usually have subscribers who's home location is in the same country. Here in the IETF, we are concerned about protocols. We can't actually mandate use. So, for the protocol, it's MUST support local/visited. I think, as a practical matter, that we all agree that MUST support home is also correct. I think within the protocol, both are MUST implement. Brian -----Original Message----- From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] Sent: Wednesday, March 22, 2006 2:52 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... I suspect it's very hard for a European country to tell US VoIP providers that they HAVE to support "local" emergency strings for anyone using the US VoIP service while in that European country. How does the European country regulate US VoIP providers and their services? Barbara > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 2:06 PM > To: 'Perry Prozeniuk'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > We've looked over the issue of > Do you HAVE to support the local/visited dialstring > Should you support the local dialstring > Do you HAVE to support the home dialstring > Should you support the home dialstring > > The result is > 1. There are regulations in most countries that REQUIRE you to > support the local dialstring > 2. There are no requirements to support the home dialstring > 3. Nearly everyone thinks it would be good to support the home > dialstring > 4. Opinions on whether you should support the local > dialstring are > mixed. Some think it screws up the dialplan so much it > shouldn't be done > > Of course, #1 above rules. So, #4 doesn't matter; you MUST > support the > local/visited dialstring. There is a lot of support for #3, > so I think we > MUST have a mechanism to support both home and local/visited > dialstrings. > Use of local/visited is a MUST. Use of home is a MAY. > > Brian > > -----Original Message----- > From: Perry Prozeniuk [mailto:perrylp@nortel.com] > Sent: Wednesday, March 22, 2006 12:49 PM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > The result, even with the special processing approach is that some > numbers may change meaning if overridden with local emergency dial > strings. The user may not be aware of this occurring and being > unfamiliar with the local emergency dial strings make accidental calls > to emergency services and won't be able to reach the service they > wanted. As Brian indicated, this is a very ugly area due to the > variation in dial plans and local emergency dial strings (enterprise > networks with their own dial plans can make it even worse). > > Perry Prozeniuk > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 12:32 PM > To: 'Stastny Richard'; 'Marc Linsner'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > The intersection of a local emergency dialstring with a home dialplan > are ugly. We looked at this in PacketCable 2.0 work. I believe the > conclusion is that with any of the methods people have for > representing > dialplans that can be automatically processed by a phone or > proxy, that > inserting the local dialstring into those dialplans is way too hard. > What you probably have to do is to just have a list of local > dialstrings > and have the interpreter have special processing that looks for them > independently of the dial plan interpretation. > > The home dial string can be imbedded in the dial plan, and > almost always > is. > > Brian > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 22, 2006 12:30 PM > To: Marc Linsner; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > I consider this very useful, and > not much additional effort > > It requires also on location infromation based on country > It could be given back with the country default PSAP(s) > if only the country is known > > I think this was also in the original cc.sos.arpa proposal from Brian > > The basic question is what happens if the local dialstring is clashing > with other local numbers. THis may be left to the user client, but we > should give some guidance here. > > Richard > > ________________________________ > > Von: Marc Linsner [mailto:mlinsner@cisco.com] > Gesendet: Mi 22.03.2006 18:12 > An: ecrit@ietf.org > Betreff: [Ecrit] Dial Strings... > > > > I want to float an idea wrt dial strings. > > We had some conversation for some time as to the value of the UA > understanding local emergency dial strings. Since we're at the end of > the requirements for LoST, please express opinion on whether > distributing local dial strings via LoST is feasible and worthy of > adding to our requirements draft. > > One example: UA boots --> UA launches LoST query and receives location > validation, PSAP uri (for fallback), and local dial strings. > > Thanks, > > -Marc- > > _______________________________________________ > 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 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 15:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9aG-0004cP-0L; Wed, 22 Mar 2006 15:05:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9aE-0004ba-R3 for ecrit@ietf.org; Wed, 22 Mar 2006 15:05:30 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9aD-00087A-JF for ecrit@ietf.org; Wed, 22 Mar 2006 15:05:30 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MK5QcL015593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 15:05:27 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MK5QOb016649; Wed, 22 Mar 2006 15:05:26 -0500 Message-ID: <4421AE08.6030107@cs.columbia.edu> Date: Wed, 22 Mar 2006 15:05:28 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Dial Strings... References: <037d01c64dd6$8f9bcb90$73818182@cis.neustar.com> <4421A743.9000004@cs.columbia.edu> <7FA8AD83-F03C-4E33-84FB-ADC9F192933B@hxr.us> In-Reply-To: <7FA8AD83-F03C-4E33-84FB-ADC9F192933B@hxr.us> 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, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: ecrit-bounces@ietf.org Right. That was the "generally" part :-) Temporarily moving ATAs and phones out of the country is probably still going to be rare. (Other residential UAs, such as soft clients, are almost exclusively using en-bloc dialing, so they don't the same set of problems.) Andrew Newton wrote: > Henning, > > I agree that we should break this down into scenarios to understand the > requirements. However, your residential case needs adjustment. There > exist today VSPs who allow their customers to take their UAs out of > their homes and plug them into other access networks, for instance at a > relatives house or in a hotel. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 15:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9aG-0004cZ-57; Wed, 22 Mar 2006 15:05:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9aF-0004bi-3h for ecrit@ietf.org; Wed, 22 Mar 2006 15:05:31 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9aE-00087B-MS for ecrit@ietf.org; Wed, 22 Mar 2006 15:05:31 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM9a6-0007uP-7w; Wed, 22 Mar 2006 14:05:22 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , Subject: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 15:05:24 -0500 Message-ID: <03ba01c64deb$f6d0cc10$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAF5XAAACwtCQAAGQqDAAAIJRMA== In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1107CA3518@bre2k61p-55> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Barbara I agree that it was tough for the U.S. to regulate Skype when it was Belgium based. As a practical matter, many carriers do obey the laws of the country where their users roam, if only because they usually have subscribers who's home location is in the same country. Here in the IETF, we are concerned about protocols. We can't actually mandate use. So, for the protocol, it's MUST support local/visited. I think, as a practical matter, that we all agree that MUST support home is also correct. I think within the protocol, both are MUST implement. Brian -----Original Message----- From: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] Sent: Wednesday, March 22, 2006 2:52 PM To: br@brianrosen.net; ecrit@ietf.org Subject: RE: [Ecrit] Dial Strings... I suspect it's very hard for a European country to tell US VoIP providers that they HAVE to support "local" emergency strings for anyone using the US VoIP service while in that European country. How does the European country regulate US VoIP providers and their services? Barbara > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 2:06 PM > To: 'Perry Prozeniuk'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > We've looked over the issue of > Do you HAVE to support the local/visited dialstring > Should you support the local dialstring > Do you HAVE to support the home dialstring > Should you support the home dialstring > > The result is > 1. There are regulations in most countries that REQUIRE you to > support the local dialstring > 2. There are no requirements to support the home dialstring > 3. Nearly everyone thinks it would be good to support the home > dialstring > 4. Opinions on whether you should support the local > dialstring are > mixed. Some think it screws up the dialplan so much it > shouldn't be done > > Of course, #1 above rules. So, #4 doesn't matter; you MUST > support the > local/visited dialstring. There is a lot of support for #3, > so I think we > MUST have a mechanism to support both home and local/visited > dialstrings. > Use of local/visited is a MUST. Use of home is a MAY. > > Brian > > -----Original Message----- > From: Perry Prozeniuk [mailto:perrylp@nortel.com] > Sent: Wednesday, March 22, 2006 12:49 PM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > The result, even with the special processing approach is that some > numbers may change meaning if overridden with local emergency dial > strings. The user may not be aware of this occurring and being > unfamiliar with the local emergency dial strings make accidental calls > to emergency services and won't be able to reach the service they > wanted. As Brian indicated, this is a very ugly area due to the > variation in dial plans and local emergency dial strings (enterprise > networks with their own dial plans can make it even worse). > > Perry Prozeniuk > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 12:32 PM > To: 'Stastny Richard'; 'Marc Linsner'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > The intersection of a local emergency dialstring with a home dialplan > are ugly. We looked at this in PacketCable 2.0 work. I believe the > conclusion is that with any of the methods people have for > representing > dialplans that can be automatically processed by a phone or > proxy, that > inserting the local dialstring into those dialplans is way too hard. > What you probably have to do is to just have a list of local > dialstrings > and have the interpreter have special processing that looks for them > independently of the dial plan interpretation. > > The home dial string can be imbedded in the dial plan, and > almost always > is. > > Brian > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 22, 2006 12:30 PM > To: Marc Linsner; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > I consider this very useful, and > not much additional effort > > It requires also on location infromation based on country > It could be given back with the country default PSAP(s) > if only the country is known > > I think this was also in the original cc.sos.arpa proposal from Brian > > The basic question is what happens if the local dialstring is clashing > with other local numbers. THis may be left to the user client, but we > should give some guidance here. > > Richard > > ________________________________ > > Von: Marc Linsner [mailto:mlinsner@cisco.com] > Gesendet: Mi 22.03.2006 18:12 > An: ecrit@ietf.org > Betreff: [Ecrit] Dial Strings... > > > > I want to float an idea wrt dial strings. > > We had some conversation for some time as to the value of the UA > understanding local emergency dial strings. Since we're at the end of > the requirements for LoST, please express opinion on whether > distributing local dial strings via LoST is feasible and worthy of > adding to our requirements draft. > > One example: UA boots --> UA launches LoST query and receives location > validation, PSAP uri (for fallback), and local dial strings. > > Thanks, > > -Marc- > > _______________________________________________ > 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 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 15:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9aG-0004cP-0L; Wed, 22 Mar 2006 15:05:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9aE-0004ba-R3 for ecrit@ietf.org; Wed, 22 Mar 2006 15:05:30 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9aD-00087A-JF for ecrit@ietf.org; Wed, 22 Mar 2006 15:05:30 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MK5QcL015593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 15:05:27 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MK5QOb016649; Wed, 22 Mar 2006 15:05:26 -0500 Message-ID: <4421AE08.6030107@cs.columbia.edu> Date: Wed, 22 Mar 2006 15:05:28 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] Dial Strings... References: <037d01c64dd6$8f9bcb90$73818182@cis.neustar.com> <4421A743.9000004@cs.columbia.edu> <7FA8AD83-F03C-4E33-84FB-ADC9F192933B@hxr.us> In-Reply-To: <7FA8AD83-F03C-4E33-84FB-ADC9F192933B@hxr.us> 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, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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: , Errors-To: ecrit-bounces@ietf.org Right. That was the "generally" part :-) Temporarily moving ATAs and phones out of the country is probably still going to be rare. (Other residential UAs, such as soft clients, are almost exclusively using en-bloc dialing, so they don't the same set of problems.) Andrew Newton wrote: > Henning, > > I agree that we should break this down into scenarios to understand the > requirements. However, your residential case needs adjustment. There > exist today VSPs who allow their customers to take their UAs out of > their homes and plug them into other access networks, for instance at a > relatives house or in a hotel. > > -andy > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 15:11:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9gR-0000tg-9M; Wed, 22 Mar 2006 15:11:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9gQ-0000s9-M3 for ecrit@ietf.org; Wed, 22 Mar 2006 15:11:54 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FM9gP-0008OF-Uo for ecrit@ietf.org; Wed, 22 Mar 2006 15:11:54 -0500 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] Dial Strings... Date: Wed, 22 Mar 2006 21:15:51 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4920@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Dial Strings... Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAF5XAAACwtCQAAGQqDAAAOeV/Q== From: "Stastny Richard" To: "Stark, Barbara" , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 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: , Errors-To: ecrit-bounces@ietf.org Good point, but ... =20 As I understand ECRIT, you may not need a VoIP provider at all to make an emergency call. If somebody is not involved, it is useless to = regulate him =20 The real question is, who will be regulated? e.g LoST and=20 the data in LoST are not a VoIP provider issue anymore, it is an issue of the emergency call takers. It is also they business to provide and run the database. =20 I always pointed out that regulation has also to change focus here: Regulators need to regulate the access providers, device manufactures, emergency call takers, etc., but nit the VoIP providers, or if the are = involved in call set up, that they recognize a dialstring and query LoST for a = given location (which they are alo not responsible for anymore =20 Richard ________________________________ Von: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] Gesendet: Mi 22.03.2006 20:52 An: br@brianrosen.net; ecrit@ietf.org Betreff: RE: [Ecrit] Dial Strings... I suspect it's very hard for a European country to tell US VoIP providers that they HAVE to support "local" emergency strings for anyone using the US VoIP service while in that European country. How does the European country regulate US VoIP providers and their services? Barbara > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 2:06 PM > To: 'Perry Prozeniuk'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > We've looked over the issue of > Do you HAVE to support the local/visited dialstring > Should you support the local dialstring > Do you HAVE to support the home dialstring > Should you support the home dialstring > > The result is > 1. There are regulations in most countries that REQUIRE you to > support the local dialstring > 2. There are no requirements to support the home dialstring > 3. Nearly everyone thinks it would be good to support the home > dialstring > 4. Opinions on whether you should support the local > dialstring are > mixed. Some think it screws up the dialplan so much it > shouldn't be done > > Of course, #1 above rules. So, #4 doesn't matter; you MUST > support the > local/visited dialstring. There is a lot of support for #3, > so I think we > MUST have a mechanism to support both home and local/visited > dialstrings. > Use of local/visited is a MUST. Use of home is a MAY. > > Brian > > -----Original Message----- > From: Perry Prozeniuk [mailto:perrylp@nortel.com] > Sent: Wednesday, March 22, 2006 12:49 PM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > The result, even with the special processing approach is that some > numbers may change meaning if overridden with local emergency dial > strings. The user may not be aware of this occurring and being > unfamiliar with the local emergency dial strings make accidental calls > to emergency services and won't be able to reach the service they > wanted. As Brian indicated, this is a very ugly area due to the > variation in dial plans and local emergency dial strings (enterprise > networks with their own dial plans can make it even worse). > > Perry Prozeniuk > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 12:32 PM > To: 'Stastny Richard'; 'Marc Linsner'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > The intersection of a local emergency dialstring with a home dialplan > are ugly. We looked at this in PacketCable 2.0 work. I believe the > conclusion is that with any of the methods people have for > representing > dialplans that can be automatically processed by a phone or > proxy, that > inserting the local dialstring into those dialplans is way too hard. > What you probably have to do is to just have a list of local > dialstrings > and have the interpreter have special processing that looks for them > independently of the dial plan interpretation. > > The home dial string can be imbedded in the dial plan, and > almost always > is. > > Brian > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 22, 2006 12:30 PM > To: Marc Linsner; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > I consider this very useful, and > not much additional effort >=20 > It requires also on location infromation based on country > It could be given back with the country default PSAP(s) > if only the country is known >=20 > I think this was also in the original cc.sos.arpa proposal from Brian >=20 > The basic question is what happens if the local dialstring is clashing > with other local numbers. THis may be left to the user client, but we > should give some guidance here. >=20 > Richard > > ________________________________ > > Von: Marc Linsner [mailto:mlinsner@cisco.com] > Gesendet: Mi 22.03.2006 18:12 > An: ecrit@ietf.org > Betreff: [Ecrit] Dial Strings... > > > > I want to float an idea wrt dial strings. > > We had some conversation for some time as to the value of the UA > understanding local emergency dial strings. Since we're at the end of > the requirements for LoST, please express opinion on whether > distributing local dial strings via LoST is feasible and worthy of > adding to our requirements draft. > > One example: UA boots --> UA launches LoST query and receives location > validation, PSAP uri (for fallback), and local dial strings. > > Thanks, > > -Marc- > > _______________________________________________ > 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 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 163 _______________________________________________ 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 Wed Mar 22 15:15:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9k2-0003sP-P0; Wed, 22 Mar 2006 15:15:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9k2-0003s7-GG for ecrit@ietf.org; Wed, 22 Mar 2006 15:15:38 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9k1-0000Bn-8n for ecrit@ietf.org; Wed, 22 Mar 2006 15:15:38 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MKDpcL017333 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 15:15:36 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MKDog5016774; Wed, 22 Mar 2006 15:13:50 -0500 Message-ID: <4421B000.5030706@cs.columbia.edu> Date: Wed, 22 Mar 2006 15:13:52 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] ECRIT Working Group Session: Summary References: <442180BD.7090707@gmx.net> In-Reply-To: <442180BD.7090707@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: , Errors-To: ecrit-bounces@ietf.org > * A Uniform Resource Name for Services > ************************************** > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-01.txt > > Based on long discussions during the meeting Henning will send a summary > of the call identification with a suggested approach on resolving the > issue. Discussions during the meeting already pointed to a preferred > approach but more discussions might be needed. As the WG may have noticed (or missed, in the flood of email...) is that I came up with a different solution to this problem. I hope it addresses the issues with doing re-mapping that were discussed in the meeting. To repeat briefly: We add a LoST operation that asks "is URL X a known PSAP URL?" The answer is "yes", "don't know" or "definitely not". Here, 'known' means "would be returned by a mapping operation". Obviously, LoST can't know about PSAP URLs that exist only outside the LoST framework. All the usual caching applies, i.e., the answer contains an indication of how long this is valid. > > Text about DDDS resolution will be removed from the draft and moved to > the LoST document. The more I think about this, the more I think this is a bad idea. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 15:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9kI-0004Cd-3n; Wed, 22 Mar 2006 15:15:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9kG-000472-Po for ecrit@ietf.org; Wed, 22 Mar 2006 15:15:52 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9kF-0000D3-Go for ecrit@ietf.org; Wed, 22 Mar 2006 15:15:52 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM9k6-0000T3-It; Wed, 22 Mar 2006 14:15:42 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Andrew Newton'" Subject: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 15:15:42 -0500 Message-ID: <03be01c64ded$68461890$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZN6/dmgdLXOfWWQmymHQFoCP1gaQAAK0nA In-Reply-To: <4421AE08.6030107@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Does that help? If it's possible, everything has to support it. If there are tradeoffs (efficiency for example), rarity can assist in selection of alternative solutions. I don't think we are there yet, we're in requirements discussion. The requirement is that we have to support local dialstrings everywhere. I do agree that an en-bloc dialing scheme makes it easier to support local dialstrings. Easier is not trivial. En-Bloc dialing still has a dial plan, with interpretation of that plan into what the device does to route the call. It doesn't affect ecrit work, it's only an aid in implementation of these things inside the dialplan interpretation element (phone or first hop proxy). Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wednesday, March 22, 2006 3:05 PM To: Andrew Newton Cc: ecrit@ietf.org Subject: Re: [Ecrit] Dial Strings... Right. That was the "generally" part :-) Temporarily moving ATAs and phones out of the country is probably still going to be rare. (Other residential UAs, such as soft clients, are almost exclusively using en-bloc dialing, so they don't the same set of problems.) Andrew Newton wrote: > Henning, > > I agree that we should break this down into scenarios to understand the > requirements. However, your residential case needs adjustment. There > exist today VSPs who allow their customers to take their UAs out of > their homes and plug them into other access networks, for instance at a > relatives house or in a hotel. > > -andy > _______________________________________________ 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 Wed Mar 22 15:29:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9x3-0003kQ-4S; Wed, 22 Mar 2006 15:29:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FM9x1-0003kL-QG for ecrit@ietf.org; Wed, 22 Mar 2006 15:29:03 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FM9x1-0000VU-AR for ecrit@ietf.org; Wed, 22 Mar 2006 15:29:03 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FM9ws-0001xU-MU; Wed, 22 Mar 2006 14:28:55 -0600 From: "Brian Rosen" To: "'Stastny Richard'" , "'Stark, Barbara'" , Subject: RE: [Ecrit] Dial Strings... Date: Wed, 22 Mar 2006 15:28:55 -0500 Message-ID: <03c201c64def$400faf10$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAF5XAAACwtCQAAGQqDAAAOeV/QAAQIjw In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4920@oefeg-s04.oefeg.loc> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Are you really arguing that support of local dialstring is not a MUST? After all, the regulation comes from the local public safety folks. They WANT the phones to do it. You can have a personal opinion, but should your opinion override theirs? Look at the actual argument: your local emergency number screws up my dial plan. The consequences of error are a call not intended to be an emergency call is turned into an emergency call. If you don't do it, you have a pristine dial plan, and someone who picks up the phone and dials the local emergency number doesn't get help, AND DOESN'T KNOW HOW to get it. My favorite foil for emergency call opt out is the baby sitter situation. You have some kind of weird behavior phone on your home office desk, which you know how to work. You go out to dinner and your kid starts choking. The babysitter picks up the phone and dials 9-1-1 (or 9-9-9 or 1-1-6). Now, what is right, and what is wrong in that scenario? Does it matter that it's rare? What is the liability for supporting local dialstring and having calls turned into emergency calls that shouldn't have been? What is the liability for not supporting local dialstrings? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, March 22, 2006 3:16 PM To: Stark, Barbara; br@brianrosen.net; ecrit@ietf.org Subject: Re: [Ecrit] Dial Strings... Good point, but ... As I understand ECRIT, you may not need a VoIP provider at all to make an emergency call. If somebody is not involved, it is useless to regulate him The real question is, who will be regulated? e.g LoST and the data in LoST are not a VoIP provider issue anymore, it is an issue of the emergency call takers. It is also they business to provide and run the database. I always pointed out that regulation has also to change focus here: Regulators need to regulate the access providers, device manufactures, emergency call takers, etc., but nit the VoIP providers, or if the are involved in call set up, that they recognize a dialstring and query LoST for a given location (which they are alo not responsible for anymore Richard ________________________________ Von: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] Gesendet: Mi 22.03.2006 20:52 An: br@brianrosen.net; ecrit@ietf.org Betreff: RE: [Ecrit] Dial Strings... I suspect it's very hard for a European country to tell US VoIP providers that they HAVE to support "local" emergency strings for anyone using the US VoIP service while in that European country. How does the European country regulate US VoIP providers and their services? Barbara > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 2:06 PM > To: 'Perry Prozeniuk'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > We've looked over the issue of > Do you HAVE to support the local/visited dialstring > Should you support the local dialstring > Do you HAVE to support the home dialstring > Should you support the home dialstring > > The result is > 1. There are regulations in most countries that REQUIRE you to > support the local dialstring > 2. There are no requirements to support the home dialstring > 3. Nearly everyone thinks it would be good to support the home > dialstring > 4. Opinions on whether you should support the local > dialstring are > mixed. Some think it screws up the dialplan so much it > shouldn't be done > > Of course, #1 above rules. So, #4 doesn't matter; you MUST > support the > local/visited dialstring. There is a lot of support for #3, > so I think we > MUST have a mechanism to support both home and local/visited > dialstrings. > Use of local/visited is a MUST. Use of home is a MAY. > > Brian > > -----Original Message----- > From: Perry Prozeniuk [mailto:perrylp@nortel.com] > Sent: Wednesday, March 22, 2006 12:49 PM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > The result, even with the special processing approach is that some > numbers may change meaning if overridden with local emergency dial > strings. The user may not be aware of this occurring and being > unfamiliar with the local emergency dial strings make accidental calls > to emergency services and won't be able to reach the service they > wanted. As Brian indicated, this is a very ugly area due to the > variation in dial plans and local emergency dial strings (enterprise > networks with their own dial plans can make it even worse). > > Perry Prozeniuk > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 12:32 PM > To: 'Stastny Richard'; 'Marc Linsner'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > The intersection of a local emergency dialstring with a home dialplan > are ugly. We looked at this in PacketCable 2.0 work. I believe the > conclusion is that with any of the methods people have for > representing > dialplans that can be automatically processed by a phone or > proxy, that > inserting the local dialstring into those dialplans is way too hard. > What you probably have to do is to just have a list of local > dialstrings > and have the interpreter have special processing that looks for them > independently of the dial plan interpretation. > > The home dial string can be imbedded in the dial plan, and > almost always > is. > > Brian > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 22, 2006 12:30 PM > To: Marc Linsner; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > I consider this very useful, and > not much additional effort > > It requires also on location infromation based on country > It could be given back with the country default PSAP(s) > if only the country is known > > I think this was also in the original cc.sos.arpa proposal from Brian > > The basic question is what happens if the local dialstring is clashing > with other local numbers. THis may be left to the user client, but we > should give some guidance here. > > Richard > > ________________________________ > > Von: Marc Linsner [mailto:mlinsner@cisco.com] > Gesendet: Mi 22.03.2006 18:12 > An: ecrit@ietf.org > Betreff: [Ecrit] Dial Strings... > > > > I want to float an idea wrt dial strings. > > We had some conversation for some time as to the value of the UA > understanding local emergency dial strings. Since we're at the end of > the requirements for LoST, please express opinion on whether > distributing local dial strings via LoST is feasible and worthy of > adding to our requirements draft. > > One example: UA boots --> UA launches LoST query and receives location > validation, PSAP uri (for fallback), and local dial strings. > > Thanks, > > -Marc- > > _______________________________________________ > 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 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163 _______________________________________________ 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 Wed Mar 22 15:36:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA4Q-0001oF-O5; Wed, 22 Mar 2006 15:36:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA4O-0001kR-MH for ecrit@ietf.org; Wed, 22 Mar 2006 15:36:40 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMA4N-0000tf-7E for ecrit@ietf.org; Wed, 22 Mar 2006 15:36:40 -0500 Received: (qmail invoked by alias); 22 Mar 2006 20:36:37 -0000 Received: from DHCP-Wireless-129-200.ietf65.org (EHLO [130.129.129.200]) [130.129.129.200] by mail.gmx.net (mp017) with SMTP; 22 Mar 2006 21:36:37 +0100 X-Authenticated: #29516787 Message-ID: <4421B557.80804@gmx.net> Date: Wed, 22 Mar 2006 14:36:39 -0600 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] ECRIT Working Group Session: Summary References: <442180BD.7090707@gmx.net> <4421B000.5030706@cs.columbia.edu> In-Reply-To: <4421B000.5030706@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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: , Errors-To: ecrit-bounces@ietf.org Hi Henning, Henning Schulzrinne wrote: > >> * A Uniform Resource Name for Services >> ************************************** >> >> http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-01.txt >> >> Based on long discussions during the meeting Henning will send a >> summary of the call identification with a suggested approach on >> resolving the issue. Discussions during the meeting already pointed to >> a preferred approach but more discussions might be needed. > > > As the WG may have noticed (or missed, in the flood of email...) is that > I came up with a different solution to this problem. I hope it addresses > the issues with doing re-mapping that were discussed in the meeting. To > repeat briefly: We add a LoST operation that asks "is URL X a known PSAP > URL?" The answer is "yes", "don't know" or "definitely not". Here, > 'known' means "would be returned by a mapping operation". Obviously, > LoST can't know about PSAP URLs that exist only outside the LoST > framework. All the usual caching applies, i.e., the answer contains an > indication of how long this is valid. > > Thanks for starting this discussion quickly after the meeting. > >> >> Text about DDDS resolution will be removed from the draft and moved to >> the LoST document. > > > The more I think about this, the more I think this is a bad idea. Hmmm. So, what could be the reason to put it into the Service URN draft? Additionally, I wasn't quite sure whether we would go for NAPTR or the S-NAPTR approach. There was an argument for the simplicity of the S-NAPTR solution but there was also the argument by Jon for just getting NAPTR right. Ciao Hannes > > Henning > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 15:40:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA7o-0004mV-Qc; Wed, 22 Mar 2006 15:40:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMA7o-0004mQ-2H for ecrit@ietf.org; Wed, 22 Mar 2006 15:40:12 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FMA7n-000130-7f for ecrit@ietf.org; Wed, 22 Mar 2006 15:40:12 -0500 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] Dial Strings... Date: Wed, 22 Mar 2006 21:44:11 +0100 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4922@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Dial Strings... Thread-Index: AcZN07vVtu77p7ObSSGbG0RGQ5uKkAAAbslxAAAnEeAAAF5XAAACwtCQAAGQqDAAAOeV/QAAQIjwAADDAGU= From: "Stastny Richard" To: , "Stark, Barbara" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 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: , Errors-To: ecrit-bounces@ietf.org >Are you really arguing that support of local dialstring is not a MUST? Could you please point out where I said said in my mail? I know it is within the scope of IETF to give advice to regulatry = bodies, and I have learned in session today (or was it yesterday?) that a MUST = in an=20 RFC is only a must for the protocol.=20 =20 A regularory MUST is something else. The question is only, who MUST (regulatory-wise) support a local = dialstring? Not the VoIP provider if he is not involved in an emergency call Richard ________________________________ Von: Brian Rosen [mailto:br@brianrosen.net] Gesendet: Mi 22.03.2006 21:28 An: Stastny Richard; 'Stark, Barbara'; ecrit@ietf.org Betreff: RE: [Ecrit] Dial Strings... Are you really arguing that support of local dialstring is not a MUST? After all, the regulation comes from the local public safety folks. = They WANT the phones to do it. You can have a personal opinion, but should = your opinion override theirs? Look at the actual argument: your local emergency number screws up my = dial plan. The consequences of error are a call not intended to be an = emergency call is turned into an emergency call. If you don't do it, you have a pristine dial plan, and someone who picks up the phone and dials the = local emergency number doesn't get help, AND DOESN'T KNOW HOW to get it. My favorite foil for emergency call opt out is the baby sitter = situation. You have some kind of weird behavior phone on your home office desk, = which you know how to work. You go out to dinner and your kid starts choking. The babysitter picks up the phone and dials 9-1-1 (or 9-9-9 or 1-1-6). Now, what is right, and what is wrong in that scenario? Does it matter = that it's rare? What is the liability for supporting local dialstring and = having calls turned into emergency calls that shouldn't have been? What is the liability for not supporting local dialstrings? Brian -----Original Message----- From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] Sent: Wednesday, March 22, 2006 3:16 PM To: Stark, Barbara; br@brianrosen.net; ecrit@ietf.org Subject: Re: [Ecrit] Dial Strings... Good point, but ... As I understand ECRIT, you may not need a VoIP provider at all to make an emergency call. If somebody is not involved, it is useless to regulate him The real question is, who will be regulated? e.g LoST and the data in LoST are not a VoIP provider issue anymore, it is an issue of the emergency call takers. It is also they business to provide and run the database. I always pointed out that regulation has also to change focus here: Regulators need to regulate the access providers, device manufactures, emergency call takers, etc., but nit the VoIP providers, or if the are involved in call set up, that they recognize a dialstring and query LoST for a = given location (which they are alo not responsible for anymore Richard ________________________________ Von: Stark, Barbara [mailto:Barbara.Stark@BellSouth.com] Gesendet: Mi 22.03.2006 20:52 An: br@brianrosen.net; ecrit@ietf.org Betreff: RE: [Ecrit] Dial Strings... I suspect it's very hard for a European country to tell US VoIP providers that they HAVE to support "local" emergency strings for anyone using the US VoIP service while in that European country. How does the European country regulate US VoIP providers and their services? Barbara > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 2:06 PM > To: 'Perry Prozeniuk'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > We've looked over the issue of > Do you HAVE to support the local/visited dialstring > Should you support the local dialstring > Do you HAVE to support the home dialstring > Should you support the home dialstring > > The result is > 1. There are regulations in most countries that REQUIRE you to > support the local dialstring > 2. There are no requirements to support the home dialstring > 3. Nearly everyone thinks it would be good to support the home > dialstring > 4. Opinions on whether you should support the local > dialstring are > mixed. Some think it screws up the dialplan so much it > shouldn't be done > > Of course, #1 above rules. So, #4 doesn't matter; you MUST > support the > local/visited dialstring. There is a lot of support for #3, > so I think we > MUST have a mechanism to support both home and local/visited > dialstrings. > Use of local/visited is a MUST. Use of home is a MAY. > > Brian > > -----Original Message----- > From: Perry Prozeniuk [mailto:perrylp@nortel.com] > Sent: Wednesday, March 22, 2006 12:49 PM > To: ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > The result, even with the special processing approach is that some > numbers may change meaning if overridden with local emergency dial > strings. The user may not be aware of this occurring and being > unfamiliar with the local emergency dial strings make accidental calls > to emergency services and won't be able to reach the service they > wanted. As Brian indicated, this is a very ugly area due to the > variation in dial plans and local emergency dial strings (enterprise > networks with their own dial plans can make it even worse). > > Perry Prozeniuk > > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Wednesday, March 22, 2006 12:32 PM > To: 'Stastny Richard'; 'Marc Linsner'; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > > The intersection of a local emergency dialstring with a home dialplan > are ugly. We looked at this in PacketCable 2.0 work. I believe the > conclusion is that with any of the methods people have for > representing > dialplans that can be automatically processed by a phone or > proxy, that > inserting the local dialstring into those dialplans is way too hard. > What you probably have to do is to just have a list of local > dialstrings > and have the interpreter have special processing that looks for them > independently of the dial plan interpretation. > > The home dial string can be imbedded in the dial plan, and > almost always > is. > > Brian > > -----Original Message----- > From: Stastny Richard [mailto:Richard.Stastny@oefeg.at] > Sent: Wednesday, March 22, 2006 12:30 PM > To: Marc Linsner; ecrit@ietf.org > Subject: RE: [Ecrit] Dial Strings... > > I consider this very useful, and > not much additional effort > > It requires also on location infromation based on country > It could be given back with the country default PSAP(s) > if only the country is known > > I think this was also in the original cc.sos.arpa proposal from Brian > > The basic question is what happens if the local dialstring is clashing > with other local numbers. THis may be left to the user client, but we > should give some guidance here. > > Richard > > ________________________________ > > Von: Marc Linsner [mailto:mlinsner@cisco.com] > Gesendet: Mi 22.03.2006 18:12 > An: ecrit@ietf.org > Betreff: [Ecrit] Dial Strings... > > > > I want to float an idea wrt dial strings. > > We had some conversation for some time as to the value of the UA > understanding local emergency dial strings. Since we're at the end of > the requirements for LoST, please express opinion on whether > distributing local dial strings via LoST is feasible and worthy of > adding to our requirements draft. > > One example: UA boots --> UA launches LoST query and receives location > validation, PSAP uri (for fallback), and local dial strings. > > Thanks, > > -Marc- > > _______________________________________________ > 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 > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by persons = or entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the material from = all computers. 163 _______________________________________________ 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 Wed Mar 22 15:52:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAK8-0007CT-5H; Wed, 22 Mar 2006 15:52:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAK6-0007CF-VD for ecrit@ietf.org; Wed, 22 Mar 2006 15:52:54 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAK5-0001hP-Of for ecrit@ietf.org; Wed, 22 Mar 2006 15:52:54 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MKqocL027335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 15:52:50 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MKqnqS016905; Wed, 22 Mar 2006 15:52:49 -0500 Message-ID: <4421B924.9030001@cs.columbia.edu> Date: Wed, 22 Mar 2006 15:52:52 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] DDDS References: <442180BD.7090707@gmx.net> <4421B000.5030706@cs.columbia.edu> <4421B557.80804@gmx.net> In-Reply-To: <4421B557.80804@gmx.net> 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, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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: , Errors-To: ecrit-bounces@ietf.org >>> Text about DDDS resolution will be removed from the draft and moved >>> to the LoST document. >> The more I think about this, the more I think this is a bad idea. > > Hmmm. So, what could be the reason to put it into the Service URN draft? > Additionally, I wasn't quite sure whether we would go for NAPTR or the > S-NAPTR approach. There was an argument for the simplicity of the > S-NAPTR solution but there was also the argument by Jon for just getting > NAPTR right. The basic question is whether service URNs would always be resolved using LoST, across all current and future services. I hope this is the case, but it seems hard to predict. If a proxy, say, gets a service URN, they should be able to consult a directory to find out which mapping protocol(s) would be used to resolve the URN. It seems to be common practice to have a URN that has enough information to do the resolution. Indeed, the 3958 examples seem to head in that general direction, although they don't use URNs as examples. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 15:59:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAQ7-0005kF-K5; Wed, 22 Mar 2006 15:59:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMAQ6-0005iN-8n for ecrit@ietf.org; Wed, 22 Mar 2006 15:59:06 -0500 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMAQ6-0002EE-0z for ecrit@ietf.org; Wed, 22 Mar 2006 15:59:06 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT41XP) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1FMAPw-0005yq-Vc; Wed, 22 Mar 2006 14:58:57 -0600 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] DDDS Date: Wed, 22 Mar 2006 15:59:02 -0500 Message-ID: <03ea01c64df3$74cb25a0$73818182@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670 Thread-Index: AcZN8pX2QIgzdsICQ3aBeYjsw3/LcAAAJj4w In-Reply-To: <4421B924.9030001@cs.columbia.edu> X-PopBeforeSMTPSenders: br@brianrosen.net X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: br@brianrosen.net List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org FWIW, I share Henning's concern. I don't want to tie urn:service to LoST. For example, there could be services that do not depend on location as the discriminator. Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Wednesday, March 22, 2006 3:53 PM To: Hannes Tschofenig Cc: ecrit@ietf.org Subject: Re: [Ecrit] DDDS >>> Text about DDDS resolution will be removed from the draft and moved >>> to the LoST document. >> The more I think about this, the more I think this is a bad idea. > > Hmmm. So, what could be the reason to put it into the Service URN draft? > Additionally, I wasn't quite sure whether we would go for NAPTR or the > S-NAPTR approach. There was an argument for the simplicity of the > S-NAPTR solution but there was also the argument by Jon for just getting > NAPTR right. The basic question is whether service URNs would always be resolved using LoST, across all current and future services. I hope this is the case, but it seems hard to predict. If a proxy, say, gets a service URN, they should be able to consult a directory to find out which mapping protocol(s) would be used to resolve the URN. It seems to be common practice to have a URN that has enough information to do the resolution. Indeed, the 3958 examples seem to head in that general direction, although they don't use URNs as examples. Henning _______________________________________________ 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 Wed Mar 22 17:17:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMBdY-0001NY-HL; Wed, 22 Mar 2006 17:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMBdW-0001NT-SP for ecrit@ietf.org; Wed, 22 Mar 2006 17:17:02 -0500 Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMBdU-0005Gy-U8 for ecrit@ietf.org; Wed, 22 Mar 2006 17:17:02 -0500 Received: from i2kc08-ukbr.domain1.systemhost.net ([193.113.197.71]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 22:16:59 +0000 Received: from i2km08-ukbr.domain1.systemhost.net ([193.113.197.82]) by i2kc08-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 22:16:58 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] Thought on citizen notification & LoST Date: Wed, 22 Mar 2006 22:16:58 -0000 Message-ID: <9D598A34672DF24F89FF4F851A41619517D2545F@i2km08-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Thought on citizen notification & LoST thread-index: AcZNxziYi3k18yVnRKuzbtR8/DECcgAAyszwAAyZs7A= From: To: , , X-OriginalArrivalTime: 22 Mar 2006 22:16:58.0947 (UTC) FILETIME=[562D2930:01C64DFE] X-Spam-Score: 0.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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: , Errors-To: ecrit-bounces@ietf.org Brian This could be a matter for debate on the list as this could be a matter for local authority as I could imagine that this is made part of the 'universal' service so an opt-in form would be inappropriate as everyone would get it as a default. As the major disadvantage for this opt-in service is maintenance costs of the database when it may only be deployed in anger once in a blue moon. The opt-in for the "send me notices of emergencies where my child is at the moment" could be a separate and even commercial service which may require a separate requirement draft? Going into solution mode would presence also be part of this service? Regards Steve -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: 22 March 2006 16:20 To: 'Andrew Newton'; 'Henning Schulzrinne' Cc: ecrit@ietf.org Subject: RE: [Ecrit] Thought on citizen notification & LoST Generally, I think this is a good idea. A problem with it is that what you REALLY want is an opt-in of the form "send me notices of emergencies where I am at the moment," which is fairly straightforward, but you also want one that was "send me notices of emergencies where my child is at the moment", which is less straightforward. The general way notification services that exist now work is that you register with an AREA of interest, and a notifier registers with an area of service. For example, Contra Costa County Sheriffs Office registers as a recipient of weather events within Contra Costa County. NOAA registers as a notifier of weather events for all of the United States. If NOAA issues an alert for four counties including Contra Costa County; the Sheriffs office gets that alert. Look at EPAD at Comcare (www.comcare.org/epad.html). Nevertheless, Henning has talked about keeping "liveness" of a mapping by tracking location relative to the service boundary of, say, a PSAP. I'm still not sure how that works, but if it did, it would be the kind of thing we want for this use. Brian =20 ________________________________________ From: Andrew Newton [mailto:andy@hxr.us]=20 Sent: Wednesday, March 22, 2006 10:42 AM To: Henning Schulzrinne Cc: 'ecrit@ietf.org' Subject: Re: [Ecrit] Thought on citizen notification & LoST On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: This is not in scope, but it might be worth keeping in mind, particularly since it seems to fit the existing model. (We'd probably define a new service URN service for that.) I was thinking exactly that. urn:service.sos.disaster-notice. And defining it in such a way, I think it might be within the scope of the working group. -andy _______________________________________________ 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 Wed Mar 22 17:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMBgc-0002UV-5P; Wed, 22 Mar 2006 17:20:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMBga-0002UH-W5 for ecrit@ietf.org; Wed, 22 Mar 2006 17:20:12 -0500 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMBgZ-0005ND-GS for ecrit@ietf.org; Wed, 22 Mar 2006 17:20:12 -0500 Received: from i2kc07-ukbr.domain1.systemhost.net ([193.113.197.14]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 22:20:10 +0000 Received: from i2km08-ukbr.domain1.systemhost.net ([193.113.197.82]) by i2kc07-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 22 Mar 2006 22:20:10 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 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] Thought on citizen notification & LoST Date: Wed, 22 Mar 2006 22:20:09 -0000 Message-ID: <9D598A34672DF24F89FF4F851A41619517D25464@i2km08-ukbr.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Thought on citizen notification & LoST thread-index: AcZN1zc4IwagaiZmSGC8tU8nWvWWRwAJzJ6A From: To: , X-OriginalArrivalTime: 22 Mar 2006 22:20:10.0213 (UTC) FILETIME=[C82E0950:01C64DFE] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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: , Errors-To: ecrit-bounces@ietf.org Henning=20 You are correct unfortunately politians tend to get very protective over what they consider to be their sovereignty Steve -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: 22 March 2006 17:36 To: br@brianrosen.net Cc: ecrit@ietf.org Subject: Re: [Ecrit] Thought on citizen notification & LoST I think we're in general agreement. I would add that a service provider=20 can choose to approximate the coverage region by a fewer-faced polygon,=20 at the cost of having overlapping polygons in the border regions. This=20 is probably harmless in practice and may even be useful since=20 emergencies rarely conform to county boundaries. Brian Rosen wrote: > I think you more or less answered the question earlier, when you=20 > described how LoST can return information that lets you determine=20 > locally if you are still in an area where the mapping remains valid. =20 > I'm still somewhat skeptical of how that works for geo (I'm guessing=20 > you have to return the entire service boundary of the service, which=20 > could be pretty large, and then the local decision is=20 > point-in-polygon). It's very nice where there are regular civic=20 > boundaries (for example, valid for the entire=20 > country/state/county...), which probably would be common. >=20 > Brian >=20 _______________________________________________ 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 Wed Mar 22 18:06:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMCOw-00077S-Kp; Wed, 22 Mar 2006 18:06:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMCOv-00074m-4o for ecrit@ietf.org; Wed, 22 Mar 2006 18:06:01 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMCOt-0007RS-SX for ecrit@ietf.org; Wed, 22 Mar 2006 18:06:01 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2MN5hcL003106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 18:05:53 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2MN5T3J017502; Wed, 22 Mar 2006 18:05:29 -0500 Message-ID: <4421D83A.5030907@cs.columbia.edu> Date: Wed, 22 Mar 2006 18:05:30 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] On DDDS discovery References: <4420C9A8.2030108@cs.columbia.edu> <915C93C4-66F4-4607-8DEF-D801791ABCE0@hxr.us> <442163C0.1080100@cs.columbia.edu> <15F2AB55-E904-4E42-8624-DA9A172DE162@hxr.us> In-Reply-To: <15F2AB55-E904-4E42-8624-DA9A172DE162@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ecrit@ietf.org, "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org > Sorry. To be specific to your earlier email, I believe both items are > covered by 3958. However, this text says something different. I don't > know what you mean by "resolver" because we are talking about DNS > resource records and the term "resolver" has a very specific meaning in > that context... one I'm hoping you are not suggesting. Sorry for the name confusion... I was talking about the LoST resolver, not the DNS resolver. > >> I'm also not quite convinced yet that we want to tie the service URN >> completely to one lookup protocol, forever and across all services. >> This seems unnecessary and unwise. > > Neither Martin nor I are suggesting any such thing, and 3958 is > obviously not saying this as the examples in that RFC are explicitly > about using multiple protocols for services. Right - but then it makes sense to have a common mechanism for the URN. > > At the moment, I am not exactly comfortable suggesting that 3958 is > applicable but the same goes for DDDS in general. That is why I said I > am confused about where this URN is being used and for what purpose. Is > this about describing the service universally or about describing a > service contextually? The abstract model is that a communication protocol (SIP, XMPP, maybe even email or HTTP...) requests to be connected to a (possibly) location-dependent abstract service, offered by many different service providers. Since the service URN isn't routable, a proxy then invokes a mapping protocol that performs the following operation: URL = function(service, [location]) where 'URL' is routable. Does that help? > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 22 18:15:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMCXh-0007VI-9r; Wed, 22 Mar 2006 18:15:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMCXg-0007VD-4l for ecrit@ietf.org; Wed, 22 Mar 2006 18:15:04 -0500 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMCXe-00080d-PX for ecrit@ietf.org; Wed, 22 Mar 2006 18:15:04 -0500 Received: from [130.129.130.179] ([::ffff:130.129.130.179]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 22 Mar 2006 18:14:09 -0500 id 01584386.4421DA41.000040F3 In-Reply-To: <4421D83A.5030907@cs.columbia.edu> References: <4420C9A8.2030108@cs.columbia.edu> <915C93C4-66F4-4607-8DEF-D801791ABCE0@hxr.us> <442163C0.1080100@cs.columbia.edu> <15F2AB55-E904-4E42-8624-DA9A172DE162@hxr.us> <4421D83A.5030907@cs.columbia.edu> Mime-Version: 1.0 (Apple Message framework v746.2) Message-Id: From: Andrew Newton Subject: Re: [Ecrit] On DDDS discovery Date: Wed, 22 Mar 2006 18:14:59 -0500 To: Henning Schulzrinne X-Mailer: Apple Mail (2.746.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: ecrit@ietf.org, "Thomson, Martin" 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="===============0993112842==" Errors-To: ecrit-bounces@ietf.org --===============0993112842== Content-Type: multipart/alternative; boundary=Apple-Mail-10--594141148 --Apple-Mail-10--594141148 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Mar 22, 2006, at 6:05 PM, Henning Schulzrinne wrote: > The abstract model is that a communication protocol (SIP, XMPP, > maybe even email or HTTP...) requests to be connected to a > (possibly) location-dependent abstract service, offered by many > different service providers. Since the service URN isn't routable, > a proxy then invokes a mapping protocol that performs the following > operation: > > URL = function(service, [location]) > > where 'URL' is routable. Is the order? 1) get URIs from LoST 2) do the URN DDDS on LoST output or 1) do URN DDDS 2) use output of URN to know which LoST servers to query -andy --Apple-Mail-10--594141148 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII
On Mar 22, 2006, = at 6:05 PM, Henning Schulzrinne wrote:

The abstract model is that a = communication protocol (SIP, XMPP, maybe even email or HTTP...) requests = to be connected to a (possibly) location-dependent abstract service, = offered by many different service providers. Since the service URN isn't = routable, a proxy then invokes a mapping protocol that performs the = following operation:


URL =3D function(service, = [location])


where 'URL' is routable.

=

Is the order?

1) get URIs from = LoST
2) do the URN DDDS on LoST output

or

1) do URN DDDS
2) = use output of URN to know which LoST servers to query

-andy
= --Apple-Mail-10--594141148-- --===============0993112842== 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 --===============0993112842==-- From ecrit-bounces@ietf.org Wed Mar 22 19:03:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMDIN-000762-RN; Wed, 22 Mar 2006 19:03:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMDIM-00075h-P6 for ecrit@ietf.org; Wed, 22 Mar 2006 19:03:18 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMDIL-0003D4-JK for ecrit@ietf.org; Wed, 22 Mar 2006 19:03:18 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2N03EcL016861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Mar 2006 19:03:14 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2N03DuE017680; Wed, 22 Mar 2006 19:03:13 -0500 Message-ID: <4421E5C3.1030509@cs.columbia.edu> Date: Wed, 22 Mar 2006 19:03:15 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] On DDDS discovery References: <4420C9A8.2030108@cs.columbia.edu> <915C93C4-66F4-4607-8DEF-D801791ABCE0@hxr.us> <442163C0.1080100@cs.columbia.edu> <15F2AB55-E904-4E42-8624-DA9A172DE162@hxr.us> <4421D83A.5030907@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, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ecrit@ietf.org, "Thomson, Martin" 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: , Errors-To: ecrit-bounces@ietf.org More than latter; in a little bit more detail: (1) do URN DDDS: obtains URL (such as http://something) for LoST (2) perform LoST operation: provides URL (e.g., SIP URL) (3) if SIP, do another DDDS/NAPTR operation (standard operation) > Is the order? > > 1) get URIs from LoST > 2) do the URN DDDS on LoST output > > or > > 1) do URN DDDS > 2) use output of URN to know which LoST servers to query > > -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 23 00:22:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMIHL-00081D-5G; Thu, 23 Mar 2006 00:22:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMIHJ-000812-H6 for ecrit@ietf.org; Thu, 23 Mar 2006 00:22:33 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMIHI-0007nc-5y for ecrit@ietf.org; Thu, 23 Mar 2006 00:22:33 -0500 Received: from razor.cs.columbia.edu (razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k2N5MTcL022351 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 23 Mar 2006 00:22:29 -0500 (EST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by razor.cs.columbia.edu (8.13.1/8.13.1) with ESMTP id k2N5MG1L018604; Thu, 23 Mar 2006 00:22:27 -0500 Message-ID: <44223082.7010604@cs.columbia.edu> Date: Thu, 23 Mar 2006 00:22:10 -0500 From: Henning Schulzrinne User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Shida Schubert Subject: Re: [Ecrit] Thought on citizen notification & LoST References: <033701c64dcf$9cf15af0$73818182@cis.neustar.com> <4421858D.1050600@cs.columbia.edu> <4421897E.3030206@ntt-at.com> In-Reply-To: <4421897E.3030206@ntt-at.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, __STOCK_CRUFT 0, __USER_AGENT 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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: , Errors-To: ecrit-bounces@ietf.org I'm not quite sure I understand your model or your concern. The number of extra LoST queries would be very small - probably about one or two a day for most users, at most. This obviously depends on the validity period of the information returned, but I don't see any reason why a subscription address would change frequently. They'd probably change about as frequently as IETF mailing list addresses... Thus, unless I'm traveling very large distances each day, always into uncharted territory, I wouldn't need to make any extra queries since the subscription address information could well be valid for days or weeks and since the user can easily cache the one or two regions they are likely to traverse during their commute. I'm expecting notification regions to be roughly of city or county size, for practical reasons. Henning Shida Schubert wrote: > > I guess other alternative is to enable people to subscribe to > user's emergency notification. > > This way, only target user will be the one needing to > query the LoST. > > 1. I would subscribe to my son's emergency notification info. > 2. When my son's UA or PUA receives an emergency notification > from emergency notification server it sends out the same information > to the subscriber who subscribed to emergency notification info. > > BTW I am concerned with frequency the LoST queries are to > be made if the service discussed here is really considered. > To really minimize the frequency of the queries, the only > way I can think of is by setting a query trigger filter based on > location range on the user device or out-bound proxy(In which > case proxy needs to store the location used in the last query for > comparison). > > Regards > Shida Schubert > > Henning Schulzrinne wrote: >> You seem to have a mediated model in mind where the end user >> subscribes to the 'emergency alerting service' and the mediator then >> provides and possibly aggregates alerts from multiple sources. The >> mediator obviously needs to subscribe to my location to make this >> work, like you indicate. >> >> In that model, the mediating service would get the location >> notifications for you (and probably lots of other people), query LoST >> and cache the results. If somebody shows up in a new area, it changes >> the alert notification or the alert subscriptions. This certainly >> doesn't require re-querying LoST for each border crossing. >> >> Henning >> >> Brian Rosen wrote: >>> What I don't think would work would be a service that got (filtered) >>> notifications of current location changes, and for each of those >>> notifications, queried LoST to determine the service notifier, and >>> when it >>> changed, initiated a new subscription to the new notifier. >>> >>> Take an example: you are on a mobile device, near a border, and moving. >>> When you first start, you are in one country, and you subscribe to that >>> country's notification service. No problem. But, you are moving. >>> Some >>> service is subscribed to your presence and tracking you (opt-in of >>> course). >>> Does that service have to continuously query using LoST to determine >>> that >>> you have crossed the boundary? Brian >>> >>> -----Original Message----- >>> From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, March >>> 22, 2006 11:31 AM >>> To: br@brianrosen.net >>> Cc: 'Andrew Newton'; 'Henning Schulzrinne'; ecrit@ietf.org >>> Subject: Re: [Ecrit] Thought on citizen notification & LoST >>> >>> >>> Hi Brian; >>> >>> I think Rohan was suggesting some draft for filtering location info >>> and event package for delivering location for the purpose of "I >>> want to know where foo is.". I guess one can use the information >>> attained through the event package mentioned above and plug >>> that into what henning is suggesting. >>> >>> Regards >>> Shida >>> >>> Brian Rosen wrote: >>>> Generally, I think this is a good idea. >>>> >>>> A problem with it is that what you REALLY want is an opt-in of the form >>>> "send me notices of emergencies where I am at the moment," which is >>>> fairly >>>> straightforward, but you also want one that was "send me notices of >>>> emergencies where my child is at the moment", which is less >>> straightforward. >>>> >>>> The general way notification services that exist now work is that you >>>> register with an AREA of interest, and a notifier registers with an >>>> area >>> of >>>> service. For example, Contra Costa County Sheriffs Office registers >>>> as a >>>> recipient of weather events within Contra Costa County. NOAA >>>> registers as >>> a >>>> notifier of weather events for all of the United States. If NOAA >>>> issues >>> an >>>> alert for four counties including Contra Costa County; the Sheriffs >>>> office >>>> gets that alert. Look at EPAD at Comcare (www.comcare.org/epad.html). >>>> >>>> Nevertheless, Henning has talked about keeping "liveness" of a >>>> mapping by >>>> tracking location relative to the service boundary of, say, a PSAP. >>>> I'm >>>> still not sure how that works, but if it did, it would be the kind of >>> thing >>>> we want for this use. >>>> >>>> Brian >>>> >>>> >>>> ________________________________________ >>>> From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, March 22, >>>> 2006 10:42 AM >>>> To: Henning Schulzrinne >>>> Cc: 'ecrit@ietf.org' >>>> Subject: Re: [Ecrit] Thought on citizen notification & LoST >>>> >>>> >>>> On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: >>>> >>>> >>>> This is not in scope, but it might be worth keeping in mind, >>>> particularly >>>> since it seems to fit the existing model. (We'd probably define a new >>>> service URN service for that.) >>>> >>>> I was thinking exactly that. urn:service.sos.disaster-notice. And >>>> defining >>>> it in such a way, I think it might be within the scope of the working >>> group. >>>> -andy >>>> >>>> >>>> _______________________________________________ >>>> 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 Mar 23 11:19:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSXN-0005lY-GD; Thu, 23 Mar 2006 11:19:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSXM-0005kc-52 for ecrit@ietf.org; Thu, 23 Mar 2006 11:19:48 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSXL-0001mE-MQ for ecrit@ietf.org; Thu, 23 Mar 2006 11:19:48 -0500 Received: from dhcp-wireless-134-205.ietf65.org ([130.129.134.205]) by dns.aliantmedia.net with esmtpa (Exim 4.52) id 1FMSXF-00030A-VC; Thu, 23 Mar 2006 10:19:42 -0600 Message-ID: <4422B9C1.9050402@ntt-at.com> Date: Thu, 23 Mar 2006 07:07:45 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Thought on citizen notification & LoST References: <033701c64dcf$9cf15af0$73818182@cis.neustar.com> <4421858D.1050600@cs.columbia.edu> <4421897E.3030206@ntt-at.com> <44223082.7010604@cs.columbia.edu> In-Reply-To: <44223082.7010604@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd 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: , Errors-To: ecrit-bounces@ietf.org Hi Henning; You have a valid point. I guess if the client queries the LoST server only when there is a change in city, state or country in its civic address, the frequency of LoST queries won't be an issue. Regards Shida Schubert Henning Schulzrinne wrote: > I'm not quite sure I understand your model or your concern. The number > of extra LoST queries would be very small - probably about one or two > a day for most users, at most. This obviously depends on the validity > period of the information returned, but I don't see any reason why a > subscription address would change frequently. They'd probably change > about as frequently as IETF mailing list addresses... Thus, unless I'm > traveling very large distances each day, always into uncharted > territory, I wouldn't need to make any extra queries since the > subscription address information could well be valid for days or weeks > and since the user can easily cache the one or two regions they are > likely to traverse during their commute. > > I'm expecting notification regions to be roughly of city or county > size, for practical reasons. > > Henning > > Shida Schubert wrote: >> >> I guess other alternative is to enable people to subscribe to >> user's emergency notification. >> >> This way, only target user will be the one needing to >> query the LoST. >> >> 1. I would subscribe to my son's emergency notification info. >> 2. When my son's UA or PUA receives an emergency notification >> from emergency notification server it sends out the same >> information >> to the subscriber who subscribed to emergency notification info. >> >> BTW I am concerned with frequency the LoST queries are to >> be made if the service discussed here is really considered. >> To really minimize the frequency of the queries, the only >> way I can think of is by setting a query trigger filter based on >> location range on the user device or out-bound proxy(In which >> case proxy needs to store the location used in the last query for >> comparison). >> >> Regards >> Shida Schubert >> >> Henning Schulzrinne wrote: >>> You seem to have a mediated model in mind where the end user >>> subscribes to the 'emergency alerting service' and the mediator then >>> provides and possibly aggregates alerts from multiple sources. The >>> mediator obviously needs to subscribe to my location to make this >>> work, like you indicate. >>> >>> In that model, the mediating service would get the location >>> notifications for you (and probably lots of other people), query >>> LoST and cache the results. If somebody shows up in a new area, it >>> changes the alert notification or the alert subscriptions. This >>> certainly doesn't require re-querying LoST for each border crossing. >>> >>> Henning >>> >>> Brian Rosen wrote: >>>> What I don't think would work would be a service that got (filtered) >>>> notifications of current location changes, and for each of those >>>> notifications, queried LoST to determine the service notifier, and >>>> when it >>>> changed, initiated a new subscription to the new notifier. >>>> >>>> Take an example: you are on a mobile device, near a border, and >>>> moving. >>>> When you first start, you are in one country, and you subscribe to >>>> that >>>> country's notification service. No problem. But, you are >>>> moving. Some >>>> service is subscribed to your presence and tracking you (opt-in of >>>> course). >>>> Does that service have to continuously query using LoST to >>>> determine that >>>> you have crossed the boundary? Brian >>>> >>>> -----Original Message----- >>>> From: Shida Schubert [mailto:shida@ntt-at.com] Sent: Wednesday, >>>> March 22, 2006 11:31 AM >>>> To: br@brianrosen.net >>>> Cc: 'Andrew Newton'; 'Henning Schulzrinne'; ecrit@ietf.org >>>> Subject: Re: [Ecrit] Thought on citizen notification & LoST >>>> >>>> >>>> Hi Brian; >>>> >>>> I think Rohan was suggesting some draft for filtering location info >>>> and event package for delivering location for the purpose of "I >>>> want to know where foo is.". I guess one can use the information >>>> attained through the event package mentioned above and plug >>>> that into what henning is suggesting. >>>> >>>> Regards >>>> Shida >>>> >>>> Brian Rosen wrote: >>>>> Generally, I think this is a good idea. >>>>> >>>>> A problem with it is that what you REALLY want is an opt-in of the >>>>> form >>>>> "send me notices of emergencies where I am at the moment," which >>>>> is fairly >>>>> straightforward, but you also want one that was "send me notices of >>>>> emergencies where my child is at the moment", which is less >>>> straightforward. >>>>> >>>>> The general way notification services that exist now work is that you >>>>> register with an AREA of interest, and a notifier registers with >>>>> an area >>>> of >>>>> service. For example, Contra Costa County Sheriffs Office >>>>> registers as a >>>>> recipient of weather events within Contra Costa County. NOAA >>>>> registers as >>>> a >>>>> notifier of weather events for all of the United States. If NOAA >>>>> issues >>>> an >>>>> alert for four counties including Contra Costa County; the >>>>> Sheriffs office >>>>> gets that alert. Look at EPAD at Comcare >>>>> (www.comcare.org/epad.html). >>>>> >>>>> Nevertheless, Henning has talked about keeping "liveness" of a >>>>> mapping by >>>>> tracking location relative to the service boundary of, say, a >>>>> PSAP. I'm >>>>> still not sure how that works, but if it did, it would be the kind of >>>> thing >>>>> we want for this use. >>>>> >>>>> Brian >>>>> >>>>> >>>>> ________________________________________ >>>>> From: Andrew Newton [mailto:andy@hxr.us] Sent: Wednesday, March >>>>> 22, 2006 10:42 AM >>>>> To: Henning Schulzrinne >>>>> Cc: 'ecrit@ietf.org' >>>>> Subject: Re: [Ecrit] Thought on citizen notification & LoST >>>>> >>>>> >>>>> On Mar 22, 2006, at 10:27 AM, Henning Schulzrinne wrote: >>>>> >>>>> >>>>> This is not in scope, but it might be worth keeping in mind, >>>>> particularly >>>>> since it seems to fit the existing model. (We'd probably define a new >>>>> service URN service for that.) >>>>> >>>>> I was thinking exactly that. urn:service.sos.disaster-notice. And >>>>> defining >>>>> it in such a way, I think it might be within the scope of the working >>>> group. >>>>> -andy >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 Mar 23 11:49:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSzn-0005o1-GJ; Thu, 23 Mar 2006 11:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMSzm-0005n0-7h for ecrit@ietf.org; Thu, 23 Mar 2006 11:49:10 -0500 Received: from mail1.nextone.com ([209.125.86.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMSzl-0002oc-RY for ecrit@ietf.org; Thu, 23 Mar 2006 11:49:10 -0500 Received: from moe.nextone.local ([192.168.15.38]) by mail1.nextone.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Mar 2006 11:49:08 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 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 Mar 2006 11:49:11 -0500 Message-ID: <8812D8156467224C9E9739E513037EF145D7E6@moe.nextone.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review comments -- draft-ietf-ecrit-requirements-06.txt thread-index: AcZDgPUuEmFUjtAsSzKrG0OBwwIU7ALFmigQ From: "Bob Natale" To: , X-OriginalArrivalTime: 23 Mar 2006 16:49:08.0734 (UTC) FILETIME=[B43A99E0:01C64E99] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: ecrit@ietf.org Subject: [Ecrit] Review comments -- draft-ietf-ecrit-requirements-06.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: , Errors-To: ecrit-bounces@ietf.org Hi, FWIW, my review comments below. This is my first review of an ECRIT document and a view of my comments are motivated by associated interest in the SPEERMINT work, so feel free to calibrate accordingly. (Also, written on a plane under less than ideal conditions. :) Overall, I think it is an excellent document (informative, well-organized), and a very good model to follow for similar documents (esp. the "Motivation" notes). Cheers, BobN - - - - C1: Sec 1., Introduction, p. 3: "This document only focuses on end-to-end IP-based calls, i.e., where the emergency call originates from an IP end system and terminates into an IP-capable PSAP, conveyed entirely over an IP network. ... Ideally, the mapping protocol would yield a URI from a preferred set of URIs (e.g., SIP:URI, SIPS:URI) which would allow an emergency call to be completed using IP end-to-end. Despite this goal, some PSAPs may not immediately have IP based connectivity, and therefore it is imperative that the URI scheme not be fixed, in order to ensure support for a less preferred set of URIs, such as a TEL URI which may be used to complete a call via the PSTN." The rationale behind the "Despite..." in the second quoted paragraph *seems* to be inconsistent with the document focus stated in the first quoted paragraph. I understand that "focus" does not mean exclusivity; but I think the gap between focus on "all IP" and a (realistic) recognition of the need to support PSTN connectivity is too wide to accept without explicit explanation in the document. I am stressing this point a bit more than I would otherwise, because I think the same (realistic) recognition might be needed in other current RAI Area efforts. C2: Sec. 2, Terminology, p. 6: NIT: The defection of ESRP needs a closing paren on the last sentence, or removal of the opening paren. C3: Sec. 2, Terminology, p. 8: The definition for VSP again brings in PSTN termination (realistic). Is this also valid for SPEERMINT consideration (perhaps especially in the Access SP entities)? C4: Sec. 4, High-Level Requirements, p. 13: The phrase "in any unusual or unreasonable way" is not sufficiently empirical -- how can compliance be verified? C5: Sec. 5, Identifying the Caller's Location, p. 14: NIT: First sentence: "direct" s/b "directly". C6: Sec. 5, Identifying the Caller's Location, p. 14: Suggest that a better moniker for Lo2 (currently "Location provided") might be "Location object/info preservation", or something like that. C7: Sec. 6, Emergency Identifiers, p. 15: Concerning the assertion in Id3 that "This marking mechanism must be different than QoS marking"...why? What, precisely, is meant by "QoS marking". Why isn't "Emergency Call" a valid QoS "marking"? Any tie-in with MLPP stuff? C8: Sec. 6, Emergency Identifiers, p. 15: Suggest that the "and" in Id5 should break it into two separate requirements. (General requirements practice of mine -- might be excessive on my part, but if accepted, might also apply to other cases in this draft). C9: Sec. 6, Emergency Identifiers, p. 16: Concerning this text in Id11 -- "MUST support (i.e., implement, though not necessarily use)": (a) I don't really understand what is meant: My supposition is that there must be at least one use case to justify implementation. What is the intended scope of "not necessarily use"? (b) [This point was made by another commenter, on an earlier version of the draft, I believe.] Regardless of (a), the various forms in which that general text (i.e., the parenthetical explanatory text following "MUST support") is used throughout the document is very confusing. C10: Sec. 7, Mapping Protocol, p. 18: the single sentence that constitutes the entire first paragraph is hard to follow -- I think there is a wording problem centered on the word "one", as well as the need for an overall re-write...? C11: Sec. 7, Mapping Protocol, p. 19: I think that the inclusion of "Motivation" statements for each requirement is a very good idea (and I propose to use it in the SPEERMINT Requirements BCP). I read that you deliberately removed that part from at least one of the requirements in this draft (e.g., Ma4). I would like to ask that "Motivation" statements be provided for all Requirements statements. It's very helpful info. - - - - - -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Wednesday, March 08, 2006 3:50 PM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-requirements-06.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Requirements for Emergency Context Resolution with Internet Technologies Author(s) : H. Schulzrinne, R. Marshall Filename : draft-ietf-ecrit-requirements-06.txt Pages : 29 Date : 2006-3-8 =09 This document enumerates requirements for the context resolution of 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-ietf-ecrit-requirements-06.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Mar 24 12:21:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpyo-00015r-Lx; Fri, 24 Mar 2006 12:21:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMpyn-00013W-PH for ecrit@ietf.org; Fri, 24 Mar 2006 12:21:41 -0500 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMpyn-0002jm-HQ for ecrit@ietf.org; Fri, 24 Mar 2006 12:21:41 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k2OHLBpg026891; Fri, 24 Mar 2006 11:21:12 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id ; Fri, 24 Mar 2006 17:21:11 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB012749167@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: br@brianrosen.net, jmpolk@cisco.com Date: Fri, 24 Mar 2006 17:21:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ecrit@ietf.org Subject: [Ecrit] Comments on draft-rosen-sos-phonebcp-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: , Errors-To: ecrit-bounces@ietf.org I had a quick look through this document and had a few comments as follows: Section 2: the list of steps involved in an emegency call. From the 3GPP perspective, and possibly also from a WiFi perspective, I would have expected the first step to talk about gaining access to some network infrastructure that supports connection to PSAPs. As you can see I'm not sure how to word this generally, but if I can give you an example of the current IMS sequence from 3GPP TS 23.167 this would involve: - establishing a GPRS connection to an emergency APN; this would lead you to a GGSN in the local network and therefore a special P-CSCF in the local network (i.e. give you an IP connection to a SIP proxy in the local network). Normal IMS operation in 3GPP may well involve a GGSN and P-CSCF in the home network, particularly in a network's early deployment, and one wants to avoid generating the emergency call through this direction if possible. - authenticating (in IMS using the REGISTER message) with both the local equipment and the home network to ensure that the phone is as claimed in later communication. Obviously this does not happen in the UICC less case, but that case is only allowed in some countries, not all. Section 6.1: We have a number of places here where the devices AoR could appear, and in this document only the From header is mentioned. - I would have expected a requirement for all headers that support the AoR to be populated if the terminal supports that extension (i.e. RFC 3325, draft-ietf-sip-identity). - Note that in the UICC less case in 3GPP, there is not necessarily any AoR. - If the user supports GRUU, should this play any part in these AoR. Section 6.1: You RECOMMEND location by-value. That is fine, but you need to discuss the conditions under which this may not be used. For example, if the reference is in the local network infrastructure, then location by reference may well be OK. If the reference is in the user's own local servers, and his house is burning down, then location by reference would be very inappropriate. There may be other comments as the work progresses. regards Keith Keith Drage Lucent Technologies drage@lucent.com tel: +44 1793 776249 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Mar 26 22:40:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FNiaU-0007Fq-B3; Sun, 26 Mar 2006 22:40:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FMw2e-00009q-0P; Fri, 24 Mar 2006 18:50:04 -0500 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FMw2c-0000bv-PB; Fri, 24 Mar 2006 18:50:03 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k2ONo19W002165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Mar 2006 23:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FMw2b-00075p-HF; Fri, 24 Mar 2006 18:50:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Fri, 24 Mar 2006 18:50:01 -0500 X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-Mailman-Approved-At: Sun, 26 Mar 2006 22:40:12 -0500 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-security-threats-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: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Security Threats and Requirements for Emergency Call Marking and Mapping Author(s) : T. Taylor, et al. Filename : draft-ietf-ecrit-security-threats-00.txt Pages : 18 Date : 2006-3-24 This document reviews the security threats associated with the two current work items of the ECRIT Working Group. The first is the marking of signalling messages to indicate that they are related to an emergency. The second is the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the threats, this document establishes a set of security requirements for the the mapping protocol and for the handling of emergency-marked calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-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-ietf-ecrit-security-threats-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-ietf-ecrit-security-threats-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: <2006-3-24164421.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-security-threats-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-security-threats-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-3-24164421.I-D@ietf.org> --OtherAccess-- --NextPart 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 --NextPart-- From ecrit-bounces@ietf.org Wed Mar 29 14:09:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOg2T-0006fi-MO; Wed, 29 Mar 2006 14:09:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOg2S-0006fd-Iq for ecrit@ietf.org; Wed, 29 Mar 2006 14:09:04 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOg2R-0004Ke-9z for ecrit@ietf.org; Wed, 29 Mar 2006 14:09:04 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 29 Mar 2006 11:09:02 -0800 X-IronPort-AV: i="4.03,144,1141632000"; d="scan'208"; a="318240082:sNHT35684136" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k2TJ8x7Z011205 for ; Wed, 29 Mar 2006 11:09:02 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 11:09:00 -0800 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Mar 2006 11:08:58 -0800 From: "Marc Linsner" To: Date: Wed, 29 Mar 2006 14:08:56 -0500 Message-ID: <012a01c65364$3b2a22d0$1f0d0d0a@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcZTZDk1NoAe/NJ5SP610aHvewXGaw== X-OriginalArrivalTime: 29 Mar 2006 19:08:59.0413 (UTC) FILETIME=[3BF11C50:01C65364] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] Hum for accepting LoST as WG item. 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: , Errors-To: ecrit-bounces@ietf.org Hi all, During the ECRIT working group meeting there was strong support to make the LoST mapping protocol document a working group item. Please speak for or against making draft-hardie-ecrit-lost-00.txt a working group item (unless you have already expressed your opinion). Deadline for responding to this hum is the 7th April 2006. Thanks, Marc & Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Mar 29 16:28:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOiDl-0006g5-D1; Wed, 29 Mar 2006 16:28:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOiDk-0006g0-29 for ecrit@ietf.org; Wed, 29 Mar 2006 16:28:52 -0500 Received: from [67.18.219.130] (helo=dns.aliantmedia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FOiDi-0001hB-QX for ecrit@ietf.org; Wed, 29 Mar 2006 16:28:52 -0500 Received: from s010600095b9792b5.vc.shawcable.net ([70.79.6.118] helo=[192.168.0.101]) by dns.aliantmedia.net with esmtpsa (SSLv3:AES256-SHA:256) (Exim 4.52) id 1FOiDh-0002mF-F9; Wed, 29 Mar 2006 15:28:49 -0600 Message-ID: <442AFC0D.2010506@ntt-at.com> Date: Wed, 29 Mar 2006 13:28:45 -0800 From: Shida Schubert User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Hum for accepting LoST as WG item. References: <012a01c65364$3b2a22d0$1f0d0d0a@amer.cisco.com> In-Reply-To: <012a01c65364$3b2a22d0$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - dns.aliantmedia.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I agree that we need something and I will hum for the draft to be accepted as a WG item, not for the status of the current draft as it lacks a lot of the detail to make any decision, but for the decision made on an interim meeting. Humm... Regards Shida Marc Linsner wrote: > Hi all, > > During the ECRIT working group meeting there was strong support to make the > LoST mapping protocol document a working group item. > > Please speak for or against making draft-hardie-ecrit-lost-00.txt a working > group item (unless you have already expressed your opinion). > > Deadline for responding to this hum is the 7th April 2006. > > Thanks, > > Marc & Hannes > > _______________________________________________ > 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 Mar 30 03:17:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsLO-0002ak-4D; Thu, 30 Mar 2006 03:17:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOsLN-0002aZ-0T for ecrit@ietf.org; Thu, 30 Mar 2006 03:17:25 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOsLI-00074T-43 for ecrit@ietf.org; Thu, 30 Mar 2006 03:17:22 -0500 Received: (qmail invoked by alias); 30 Mar 2006 08:17:18 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp019) with SMTP; 30 Mar 2006 10:17:18 +0200 X-Authenticated: #29516787 Message-ID: <442B9408.3020604@gmx.net> Date: Thu, 30 Mar 2006 10:17:12 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] IETF#65 Meeting Minutes 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: , Errors-To: ecrit-bounces@ietf.org Hi all, please take a look at the meeting minutes: http://www3.ietf.org/proceedings/06mar/minutes/ecrit.txt The Jabber log can be found at: http://www.ietf.org/meetings/ietf-logs/ecrit@rooms.jabber.ietf.org/2006-03-21.html Thanks to Spencer for the meeting minutes. Thanks to Ted for being the jabber scribe. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Mar 30 06:12:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOv52-0000La-HF; Thu, 30 Mar 2006 06:12:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FOv51-0000LQ-C8 for ecrit@ietf.org; Thu, 30 Mar 2006 06:12:43 -0500 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FOv50-0005yD-0u for ecrit@ietf.org; Thu, 30 Mar 2006 06:12:43 -0500 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: RE: [Ecrit] Hum for accepting LoST as WG item. Date: Thu, 30 Mar 2006 13:16:30 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D463C4E8F@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for accepting LoST as WG item. Thread-Index: AcZTZDk1NoAe/NJ5SP610aHvewXGawAhua5w From: "Stastny Richard" To: "Marc Linsner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: ecrit-bounces@ietf.org Hum, I agree to make lost a WG item Richard > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, March 29, 2006 9:09 PM > To: ecrit@ietf.org > Subject: [Ecrit] Hum for accepting LoST as WG item. >=20 > Hi all, >=20 > During the ECRIT working group meeting there was strong support to make > the > LoST mapping protocol document a working group item. >=20 > Please speak for or against making draft-hardie-ecrit-lost-00.txt a > working > group item (unless you have already expressed your opinion). >=20 > Deadline for responding to this hum is the 7th April 2006. >=20 > Thanks, >=20 > Marc & Hannes >=20 > _______________________________________________ > 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 Mar 30 14:00:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2NT-0000BX-1V; Thu, 30 Mar 2006 14:00:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP2NS-0000BS-9i for ecrit@ietf.org; Thu, 30 Mar 2006 14:00:14 -0500 Received: from dnsmx1rrc.telcordia.com ([128.96.20.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP2NR-0003Oa-09 for ecrit@ietf.org; Thu, 30 Mar 2006 14:00:14 -0500 Received: from pya-dte-ieg01.cc.telcordia.com (pya-dte-ieg01.cc.telcordia.com [128.96.20.21]) by dnsmx1rrc.telcordia.com (8.11.7+Sun/8.9.3) with SMTP id k2UJ08210598; Thu, 30 Mar 2006 14:00:08 -0500 (EST) Received: from rrc-dte-exbh01.dte.telcordia.com ([128.96.150.31]) by pya-dte-ieg01.cc.telcordia.com (SMSSMTP 4.1.9.35) with SMTP id M2006033014000328850 ; Thu, 30 Mar 2006 14:00:03 -0500 Received: from rrc-dte-exs01.dte.telcordia.com ([128.96.150.34]) by rrc-dte-exbh01.dte.telcordia.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 30 Mar 2006 14:00:03 -0500 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: RE: [Ecrit] Hum for accepting LoST as WG item. Date: Thu, 30 Mar 2006 14:00:02 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for accepting LoST as WG item. Thread-Index: AcZTZDk1NoAe/NJ5SP610aHvewXGawAx0Epg From: "Abbott, Nadine B" To: "Marc Linsner" , X-OriginalArrivalTime: 30 Mar 2006 19:00:03.0579 (UTC) FILETIME=[26F914B0:01C6542C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: ecrit-bounces@ietf.org I support making the LoST mapping protocol an ECRIT WG item.=20 (Although maybe we could figure out an appropriate name to go with FOUND...?) Nadine -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of Marc Linsner Sent: Wednesday, March 29, 2006 2:09 PM To: ecrit@ietf.org Subject: [Ecrit] Hum for accepting LoST as WG item. Hi all, During the ECRIT working group meeting there was strong support to make the LoST mapping protocol document a working group item. Please speak for or against making draft-hardie-ecrit-lost-00.txt a working group item (unless you have already expressed your opinion). Deadline for responding to this hum is the 7th April 2006. Thanks, Marc & Hannes _______________________________________________ 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 Mar 30 15:04:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3Nc-0001rV-5W; Thu, 30 Mar 2006 15:04:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP3Nb-0001rQ-Q3 for ecrit@ietf.org; Thu, 30 Mar 2006 15:04:27 -0500 Received: from zrtps0kp.nortelnetworks.com ([47.140.192.56] helo=zrtps0kp.nortel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP3Na-0005dV-H6 for ecrit@ietf.org; Thu, 30 Mar 2006 15:04:27 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k2UK4LA27401; Thu, 30 Mar 2006 15:04:21 -0500 (EST) Received: from [127.0.0.1] ([47.130.16.16] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 30 Mar 2006 15:04:20 -0500 Message-ID: <442C39C0.9070703@nortel.com> Date: Thu, 30 Mar 2006 15:04:16 -0500 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marc Linsner Subject: Re: [Ecrit] Hum for accepting LoST as WG item. References: <012a01c65364$3b2a22d0$1f0d0d0a@amer.cisco.com> In-Reply-To: <012a01c65364$3b2a22d0$1f0d0d0a@amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Mar 2006 20:04:20.0712 (UTC) FILETIME=[2200DE80:01C65435] X-Spam-Score: 0.1 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: , Errors-To: ecrit-bounces@ietf.org I support making draft-hardie-ecrit-lost-00.txt a working group item. Marc Linsner wrote: > Hi all, > > During the ECRIT working group meeting there was strong support to make the > LoST mapping protocol document a working group item. > > Please speak for or against making draft-hardie-ecrit-lost-00.txt a working > group item (unless you have already expressed your opinion). > > Deadline for responding to this hum is the 7th April 2006. > > Thanks, > > Marc & Hannes > > _______________________________________________ > 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 Mar 30 16:40:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4sl-0005tF-9E; Thu, 30 Mar 2006 16:40:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FP4sk-0005tA-FU for ecrit@ietf.org; Thu, 30 Mar 2006 16:40:42 -0500 Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FP4si-00015P-Uw for ecrit@ietf.org; Thu, 30 Mar 2006 16:40:42 -0500 Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.6]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id ; Thu, 30 Mar 2006 13:40:38 -0800 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: RE: [Ecrit] Hum for accepting LoST as WG item. Date: Thu, 30 Mar 2006 13:40:37 -0800 Message-ID: <8C837214C95C864C9F34F3635C2A657504985085@SEA-EXCHVS-2.telecomsys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for accepting LoST as WG item. Thread-Index: AcZTZDk1NoAe/NJ5SP610aHvewXGawAzq73Q From: "Roger Marshall" To: "Marc Linsner" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Errors-To: ecrit-bounces@ietf.org Here's a yes Hum for accepting draft-hardie-ecrit-lost-00.txt a wg item. Roger Marshall >-----Original Message----- >From: Marc Linsner [mailto:mlinsner@cisco.com]=20 >Sent: Wednesday, March 29, 2006 11:09 AM >To: ecrit@ietf.org >Subject: [Ecrit] Hum for accepting LoST as WG item. > >Hi all, > >During the ECRIT working group meeting there was strong=20 >support to make the LoST mapping protocol document a working=20 >group item. > >Please speak for or against making=20 >draft-hardie-ecrit-lost-00.txt a working group item (unless=20 >you have already expressed your opinion). > >Deadline for responding to this hum is the 7th April 2006. > >Thanks, > >Marc & Hannes > >_______________________________________________ >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