From nobody Fri Oct 2 14:38:38 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320EE1B2F26; Fri, 2 Oct 2015 14:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvFK1JYhOYVA; Fri, 2 Oct 2015 14:38:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FF271B2F29; Fri, 2 Oct 2015 14:38:32 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t92LcUDI078696 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 2 Oct 2015 16:38:30 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Randall Gellens" Date: Fri, 02 Oct 2015 16:38:30 -0500 Message-ID: <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> In-Reply-To: References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org, The IESG Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2015 21:38:34 -0000 Oops, I just ran across this going back over old messages. I don't think I responded; apologies for that. Comments inline. I deleted sections that don't seem to need further discussion. Thanks! Ben. On 13 Sep 2015, at 18:51, Randall Gellens wrote: [...] >>> >> [Edit: I asked a question below about what happens if you dereference >> a >> block, and find the URL points to something other than what you >> expected. >> On reflection, I should expand that to ask how dereferencing errors >> should be handled in general.] > > In general, since this is an emergency call, we want the call to go > through even if there are errors. It's better that the call go > through with some data blocks missing or unusable than for the call to > fail. That makes sense--is there any text that says that? If not, it might be worth adding. [...] >>> This draft implicitly assumes that the emergency calls are signaled >>> with >> SIP. I don't dispute that assumption, but I think it should it's >> worth a >> paragraph stating it explicitly. > > The Introduction says: > > This document extends the basic set of data communicated with an IP- > based emergency call, as described in [RFC6443] and [RFC6881] > > Both those RFCs are explicitly SIP-based. However, I'd be happy to > change the text from "IP-based" to "SIP-based" if people feel it would > add clarity. E.g., to: > > This document extends the basic set of data communicated with a SIP- > based emergency call, as described in [RFC6443] and [RFC6881] > > Or perhaps to: > > This document extends the basic set of data communicated with a > Session Initiation Protocol (SIP) based emergency call, as > described in [RFC6443] and [RFC6881] > > Let me know if you feel this change would be helpful. I think the second version would be helpful. [...] > >> -- 3: >> Is there a critical need for the bit about "certain private-use >> situations"? That seems like license for abuse, without more >> elaboration >> about "prexisting relationship" and "privacy issues addressed". > > The reason for that text is to permit re-use of the mechanisms within > private telematics calls between a vehicle and a telematics service > center (which in turn simplifies the use of the mechanisms when such > calls are emergency calls from the telematics service center to a > PSAP). The text appears as an exception to a ban on using the > mechanisms outside of an emergency call, so without it, such use would > be violating the RFC. I thought the text was pretty restrictive, > since it says: > > certain private-use situations where the endpoints > have a preexisting relationship and privacy issues are addressed > within the relationship or do not apply because of it > > If you still feel this text is a "license for abuse" I'd be open to > tightening it, but it seems pretty limited to me. Thanks for the explanation. I can live with what's there. [...] > >> -- 4.1.5: >> Do you intend 24x7 support to be a prerequisite to be a data >> provider? > > It's not within scope of the IETF to make this requirement, but the > expectation is that calls will be processed by mainstream providers > who have 24/7 support for PSAPs. The descriptions says "...information MUST be a URI to a 24/7 support organization..." That sounds like the IETF is making the requirement. I'd be happy to have a non-normative statement that this is expected by the community to be a 24/7 support organization, but the MUST doesn't seem to fit. >> Also, it seems like there are vcard fields that are not useful to >> this >> purpose and might still have privacy implications. Do we really need >> people >> to send everything? > > The text does not mandate which fields to send. It encourages sending > all fields because there are some unusual circumstances where a > seemingly irrelevant field might be useful to a call-taker (e.g., > anniversary might conceivably be useful with a suicidal caller) and > suggests a minimum set. I think there needs to be a balance between "conceivably useful" and "likely to be privacy-sensitive". But IIRC, this discussion is happening separately, isn't it? [...] >> -- 5, list item 1: "The "purpose" parameter also indicates the kind >> of >> data >> (by its MIME subtype) that is available at the URI" >> What happens if the URL points to something other than the indicated >> thing? > > Then the PSAP doesn't get what it expects, and likely will ignore the > retrieved data, and the call will be processed as if the block wasn't > provided at all. The PSAP will likely file a discrepancy report with > the provider, which is done out of band. If the information in the > block is potentially urgent for handling the call, the call-taker or a > supervisor might contact the provider's PSAP support line. That's probably fine, although I wonder if there might be room for guidance that the PSAP shouldn't just load arbitrary data if it gets something unexpected. [...] >> -- 8: >> It might be worth discussing the potential harm done by a malicious >> proxy >> modifying a data element, or a compromised data source return >> incorrect >> information when dereferencing a URL. > > If an element in the call path is compromised and under the control of > an attacker, it can wreak havoc, but this is generally true for any > system that isn't using end-to-end protection, and even then is true > if an endpoint is compromised. I'm not sure what would be helpful to > say about this in the Security Considerations section. I'm not going to push the point--but keep in mind the "compromised data source" case involves something _not_ in the call path. [...] From nobody Sat Oct 3 05:10:37 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCC61A0A85 for ; Sat, 3 Oct 2015 05:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnzH8f8gn7uV for ; Sat, 3 Oct 2015 05:10:32 -0700 (PDT) Received: from bin-vsp-out-04.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ECFA1A0AF1 for ; Sat, 3 Oct 2015 05:10:31 -0700 (PDT) X-Halon-ID: b9e0b5ee-69c7-11e5-bfe4-005056917c0c Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-04.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Sat, 3 Oct 2015 14:10:24 +0200 (CEST) To: Ben Campbell , Randall Gellens References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <560FC5AF.3090302@omnitor.se> Date: Sat, 3 Oct 2015 14:10:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 12:10:36 -0000 A comment on the 24/7 discussion on section 4.1.5: Relay services are supposed to be data providers. Sadly, the deployment of relay services is very slow in some regions, and if they exist, they often operate limited hours. This is of course a problem when making emergency calls, but the wording in 4.1.5 should not discourage relay services from registering and providing data because they currently have limited opening hours. ---------------- Another issue around relay services: It would be good to get a URI that can be used for bridging in the relay service together with a call-back. This is because the relay service might have been invoked in a way so that the call-back address to the original caller does not automatically invoke the relay service. None of the provided data seem to specify that kind of URI. ---------------- /Gunnar Hellstrom Den 2015-10-02 kl. 23:38, skrev Ben Campbell: > Oops, I just ran across this going back over old messages. I don't > think I responded; apologies for that. Comments inline. I deleted > sections that don't seem to need further discussion. > > Thanks! > > Ben. > > On 13 Sep 2015, at 18:51, Randall Gellens wrote: > > [...] > >>>> >>> [Edit: I asked a question below about what happens if you dereference a >>> block, and find the URL points to something other than what you >>> expected. >>> On reflection, I should expand that to ask how dereferencing errors >>> should be handled in general.] >> >> In general, since this is an emergency call, we want the call to go >> through even if there are errors. It's better that the call go >> through with some data blocks missing or unusable than for the call >> to fail. > > That makes sense--is there any text that says that? If not, it might > be worth adding. > > [...] > >>>> This draft implicitly assumes that the emergency calls are signaled >>>> with >>> SIP. I don't dispute that assumption, but I think it should it's >>> worth a >>> paragraph stating it explicitly. >> >> The Introduction says: >> >> This document extends the basic set of data communicated with an IP- >> based emergency call, as described in [RFC6443] and [RFC6881] >> >> Both those RFCs are explicitly SIP-based. However, I'd be happy to >> change the text from "IP-based" to "SIP-based" if people feel it >> would add clarity. E.g., to: >> >> This document extends the basic set of data communicated with a SIP- >> based emergency call, as described in [RFC6443] and [RFC6881] >> >> Or perhaps to: >> >> This document extends the basic set of data communicated with a >> Session Initiation Protocol (SIP) based emergency call, as >> described in [RFC6443] and [RFC6881] >> >> Let me know if you feel this change would be helpful. > > I think the second version would be helpful. > > > [...] > >> >>> -- 3: >>> Is there a critical need for the bit about "certain private-use >>> situations"? That seems like license for abuse, without more >>> elaboration >>> about "prexisting relationship" and "privacy issues addressed". >> >> The reason for that text is to permit re-use of the mechanisms within >> private telematics calls between a vehicle and a telematics service >> center (which in turn simplifies the use of the mechanisms when such >> calls are emergency calls from the telematics service center to a >> PSAP). The text appears as an exception to a ban on using the >> mechanisms outside of an emergency call, so without it, such use >> would be violating the RFC. I thought the text was pretty >> restrictive, since it says: >> >> certain private-use situations where the endpoints >> have a preexisting relationship and privacy issues are addressed >> within the relationship or do not apply because of it >> >> If you still feel this text is a "license for abuse" I'd be open to >> tightening it, but it seems pretty limited to me. > > Thanks for the explanation. I can live with what's there. > > [...] > >> >>> -- 4.1.5: >>> Do you intend 24x7 support to be a prerequisite to be a data >>> provider? >> >> It's not within scope of the IETF to make this requirement, but the >> expectation is that calls will be processed by mainstream providers >> who have 24/7 support for PSAPs. > > > The descriptions says "...information MUST be a URI to a 24/7 support > organization..." That sounds like the IETF is making the requirement. > > I'd be happy to have a non-normative statement that this is expected > by the community to be a 24/7 support organization, but the MUST > doesn't seem to fit. > >>> Also, it seems like there are vcard fields that are not useful to this >>> purpose and might still have privacy implications. Do we really need >>> people >>> to send everything? >> >> The text does not mandate which fields to send. It encourages >> sending all fields because there are some unusual circumstances where >> a seemingly irrelevant field might be useful to a call-taker (e.g., >> anniversary might conceivably be useful with a suicidal caller) and >> suggests a minimum set. > > I think there needs to be a balance between "conceivably useful" and > "likely to be privacy-sensitive". But IIRC, this discussion is > happening separately, isn't it? > > [...] > >>> -- 5, list item 1: "The "purpose" parameter also indicates the kind of >>> data >>> (by its MIME subtype) that is available at the URI" >>> What happens if the URL points to something other than the indicated >>> thing? >> >> Then the PSAP doesn't get what it expects, and likely will ignore the >> retrieved data, and the call will be processed as if the block wasn't >> provided at all. The PSAP will likely file a discrepancy report with >> the provider, which is done out of band. If the information in the >> block is potentially urgent for handling the call, the call-taker or >> a supervisor might contact the provider's PSAP support line. > > That's probably fine, although I wonder if there might be room for > guidance that the PSAP shouldn't just load arbitrary data if it gets > something unexpected. > > [...] >>> -- 8: >>> It might be worth discussing the potential harm done by a malicious >>> proxy >>> modifying a data element, or a compromised data source return incorrect >>> information when dereferencing a URL. >> >> If an element in the call path is compromised and under the control >> of an attacker, it can wreak havoc, but this is generally true for >> any system that isn't using end-to-end protection, and even then is >> true if an endpoint is compromised. I'm not sure what would be >> helpful to say about this in the Security Considerations section. > > I'm not going to push the point--but keep in mind the "compromised > data source" case involves something _not_ in the call path. > > [...] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Sat Oct 3 11:51:53 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F631A1B40 for ; Sat, 3 Oct 2015 11:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJwjwppW032a for ; Sat, 3 Oct 2015 11:51:49 -0700 (PDT) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ACD61A1B34 for ; Sat, 3 Oct 2015 11:51:49 -0700 (PDT) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-09v.sys.comcast.net with comcast id Qir01r0032VvR6D01iro9U; Sat, 03 Oct 2015 18:51:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-19v.sys.comcast.net with comcast id Qirn1r00Z3Ge9ey01iropb; Sat, 03 Oct 2015 18:51:48 +0000 To: ecrit@ietf.org References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> <560FC5AF.3090302@omnitor.se> From: Paul Kyzivat Message-ID: <561023C2.3080507@alum.mit.edu> Date: Sat, 3 Oct 2015 14:51:46 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <560FC5AF.3090302@omnitor.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1443898308; bh=CfiAlBDfGP9Nl9UZVCXdUcX7pabOJJl7TBxwGMrwCCk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=PpCpNIqRHx66fo30EEHxeD/66zrhM335Ffd6yBwnV13SPNfzJKAUjPRFcu9KQK4hG FDur+ztXx9rO7g35tszO4TFTqHy4cN9rhW/5YdBlRyg9FF774m+67uQy6tbqGiMrab i6vVv23+Xlu2aNUWbgBI2kJVXM/S5edbh9K9henCFK6+pnudZeKUSVgIlhsJD8Inh4 i84FIEgJq9Ze/axZnLo19lB+3Q268hBeXIK81q+ZC/lT+4ZlN0aNqBymbuiGJIQOT2 uu0dYgSMsqb+9PGFZb2THLiHMmTflwZQuUKeIoISB3+Po95jqOobRkpvANHPVNMN+4 HB6WE7mF0vo9Q== Archived-At: Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 18:51:51 -0000 On 10/3/15 8:10 AM, Gunnar Hellström wrote: > A comment on the 24/7 discussion on section 4.1.5: > Relay services are supposed to be data providers. > Sadly, the deployment of relay services is very slow in some regions, > and if they exist, they often operate limited hours. > This is of course a problem when making emergency calls, but the wording > in 4.1.5 should not discourage relay services from registering and > providing data because they currently have limited opening hours. > ---------------- > Another issue around relay services: It would be good to get a URI that > can be used for bridging in the relay service together with a call-back. > This is because the relay service might have been invoked in a way so > that the call-back address to the original caller does not automatically > invoke the relay service. None of the provided data seem to specify that > kind of URI. > ---------------- If the relay service was included in such a way that callbacks don't bring it back in, then having the URL of the relay service won't necessarily mean that the entity doing the callback will be authorized to obtain relay services on the callback call. I don't see a good way to solve that except for the relay service to be authorized based on whichever end of the call desires/needs the relay service. Thanks, Paul > /Gunnar Hellstrom > > Den 2015-10-02 kl. 23:38, skrev Ben Campbell: >> Oops, I just ran across this going back over old messages. I don't >> think I responded; apologies for that. Comments inline. I deleted >> sections that don't seem to need further discussion. >> >> Thanks! >> >> Ben. >> >> On 13 Sep 2015, at 18:51, Randall Gellens wrote: >> >> [...] >> >>>>> >>>> [Edit: I asked a question below about what happens if you dereference a >>>> block, and find the URL points to something other than what you >>>> expected. >>>> On reflection, I should expand that to ask how dereferencing errors >>>> should be handled in general.] >>> >>> In general, since this is an emergency call, we want the call to go >>> through even if there are errors. It's better that the call go >>> through with some data blocks missing or unusable than for the call >>> to fail. >> >> That makes sense--is there any text that says that? If not, it might >> be worth adding. >> >> [...] >> >>>>> This draft implicitly assumes that the emergency calls are signaled >>>>> with >>>> SIP. I don't dispute that assumption, but I think it should it's >>>> worth a >>>> paragraph stating it explicitly. >>> >>> The Introduction says: >>> >>> This document extends the basic set of data communicated with an IP- >>> based emergency call, as described in [RFC6443] and [RFC6881] >>> >>> Both those RFCs are explicitly SIP-based. However, I'd be happy to >>> change the text from "IP-based" to "SIP-based" if people feel it >>> would add clarity. E.g., to: >>> >>> This document extends the basic set of data communicated with a SIP- >>> based emergency call, as described in [RFC6443] and [RFC6881] >>> >>> Or perhaps to: >>> >>> This document extends the basic set of data communicated with a >>> Session Initiation Protocol (SIP) based emergency call, as >>> described in [RFC6443] and [RFC6881] >>> >>> Let me know if you feel this change would be helpful. >> >> I think the second version would be helpful. >> >> >> [...] >> >>> >>>> -- 3: >>>> Is there a critical need for the bit about "certain private-use >>>> situations"? That seems like license for abuse, without more >>>> elaboration >>>> about "prexisting relationship" and "privacy issues addressed". >>> >>> The reason for that text is to permit re-use of the mechanisms within >>> private telematics calls between a vehicle and a telematics service >>> center (which in turn simplifies the use of the mechanisms when such >>> calls are emergency calls from the telematics service center to a >>> PSAP). The text appears as an exception to a ban on using the >>> mechanisms outside of an emergency call, so without it, such use >>> would be violating the RFC. I thought the text was pretty >>> restrictive, since it says: >>> >>> certain private-use situations where the endpoints >>> have a preexisting relationship and privacy issues are addressed >>> within the relationship or do not apply because of it >>> >>> If you still feel this text is a "license for abuse" I'd be open to >>> tightening it, but it seems pretty limited to me. >> >> Thanks for the explanation. I can live with what's there. >> >> [...] >> >>> >>>> -- 4.1.5: >>>> Do you intend 24x7 support to be a prerequisite to be a data >>>> provider? >>> >>> It's not within scope of the IETF to make this requirement, but the >>> expectation is that calls will be processed by mainstream providers >>> who have 24/7 support for PSAPs. >> >> >> The descriptions says "...information MUST be a URI to a 24/7 support >> organization..." That sounds like the IETF is making the requirement. >> >> I'd be happy to have a non-normative statement that this is expected >> by the community to be a 24/7 support organization, but the MUST >> doesn't seem to fit. >> >>>> Also, it seems like there are vcard fields that are not useful to this >>>> purpose and might still have privacy implications. Do we really need >>>> people >>>> to send everything? >>> >>> The text does not mandate which fields to send. It encourages >>> sending all fields because there are some unusual circumstances where >>> a seemingly irrelevant field might be useful to a call-taker (e.g., >>> anniversary might conceivably be useful with a suicidal caller) and >>> suggests a minimum set. >> >> I think there needs to be a balance between "conceivably useful" and >> "likely to be privacy-sensitive". But IIRC, this discussion is >> happening separately, isn't it? >> >> [...] >> >>>> -- 5, list item 1: "The "purpose" parameter also indicates the kind of >>>> data >>>> (by its MIME subtype) that is available at the URI" >>>> What happens if the URL points to something other than the indicated >>>> thing? >>> >>> Then the PSAP doesn't get what it expects, and likely will ignore the >>> retrieved data, and the call will be processed as if the block wasn't >>> provided at all. The PSAP will likely file a discrepancy report with >>> the provider, which is done out of band. If the information in the >>> block is potentially urgent for handling the call, the call-taker or >>> a supervisor might contact the provider's PSAP support line. >> >> That's probably fine, although I wonder if there might be room for >> guidance that the PSAP shouldn't just load arbitrary data if it gets >> something unexpected. >> >> [...] >>>> -- 8: >>>> It might be worth discussing the potential harm done by a malicious >>>> proxy >>>> modifying a data element, or a compromised data source return incorrect >>>> information when dereferencing a URL. >>> >>> If an element in the call path is compromised and under the control >>> of an attacker, it can wreak havoc, but this is generally true for >>> any system that isn't using end-to-end protection, and even then is >>> true if an endpoint is compromised. I'm not sure what would be >>> helpful to say about this in the Security Considerations section. >> >> I'm not going to push the point--but keep in mind the "compromised >> data source" case involves something _not_ in the call path. >> >> [...] >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Sat Oct 3 14:58:19 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AC81A88CE for ; Sat, 3 Oct 2015 14:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JtrIET-zZRWV for ; Sat, 3 Oct 2015 14:58:15 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C031A872A for ; Sat, 3 Oct 2015 14:58:14 -0700 (PDT) X-Halon-ID: d52d31eb-6a19-11e5-98bf-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA for ; Sat, 3 Oct 2015 23:58:08 +0200 (CEST) To: ecrit@ietf.org References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> <560FC5AF.3090302@omnitor.se> <561023C2.3080507@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <56104F6F.1010301@omnitor.se> Date: Sat, 3 Oct 2015 23:58:07 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <561023C2.3080507@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Oct 2015 21:58:18 -0000 Den 2015-10-03 kl. 20:51, skrev Paul Kyzivat: > On 10/3/15 8:10 AM, Gunnar Hellström wrote: >> A comment on the 24/7 discussion on section 4.1.5: >> Relay services are supposed to be data providers. >> Sadly, the deployment of relay services is very slow in some regions, >> and if they exist, they often operate limited hours. >> This is of course a problem when making emergency calls, but the wording >> in 4.1.5 should not discourage relay services from registering and >> providing data because they currently have limited opening hours. >> ---------------- >> Another issue around relay services: It would be good to get a URI that >> can be used for bridging in the relay service together with a call-back. >> This is because the relay service might have been invoked in a way so >> that the call-back address to the original caller does not automatically >> invoke the relay service. None of the provided data seem to specify that >> kind of URI. >> ---------------- > > If the relay service was included in such a way that callbacks don't > bring it back in, then having the URL of the relay service won't > necessarily mean that the entity doing the callback will be authorized > to obtain relay services on the callback call. > > I don't see a good way to solve that except for the relay service to > be authorized based on whichever end of the call desires/needs the > relay service. Yes, that would be included in a recommendation for how to use a URL field in Additional-Data. A region could have requirements that the relay services who are registered as data providers also authorize calls from the region. But it would be equally good if you can propose another field to convey such an URL in. It does not seem to be the intention of Additional-Data to provide operational information. > > Thanks, > Paul > >> /Gunnar Hellstrom >> >> Den 2015-10-02 kl. 23:38, skrev Ben Campbell: >>> Oops, I just ran across this going back over old messages. I don't >>> think I responded; apologies for that. Comments inline. I deleted >>> sections that don't seem to need further discussion. >>> >>> Thanks! >>> >>> Ben. >>> >>> On 13 Sep 2015, at 18:51, Randall Gellens wrote: >>> >>> [...] >>> >>>>>> >>>>> [Edit: I asked a question below about what happens if you >>>>> dereference a >>>>> block, and find the URL points to something other than what you >>>>> expected. >>>>> On reflection, I should expand that to ask how dereferencing errors >>>>> should be handled in general.] >>>> >>>> In general, since this is an emergency call, we want the call to go >>>> through even if there are errors. It's better that the call go >>>> through with some data blocks missing or unusable than for the call >>>> to fail. >>> >>> That makes sense--is there any text that says that? If not, it might >>> be worth adding. >>> >>> [...] >>> >>>>>> This draft implicitly assumes that the emergency calls are signaled >>>>>> with >>>>> SIP. I don't dispute that assumption, but I think it should it's >>>>> worth a >>>>> paragraph stating it explicitly. >>>> >>>> The Introduction says: >>>> >>>> This document extends the basic set of data communicated with an IP- >>>> based emergency call, as described in [RFC6443] and [RFC6881] >>>> >>>> Both those RFCs are explicitly SIP-based. However, I'd be happy to >>>> change the text from "IP-based" to "SIP-based" if people feel it >>>> would add clarity. E.g., to: >>>> >>>> This document extends the basic set of data communicated with a SIP- >>>> based emergency call, as described in [RFC6443] and [RFC6881] >>>> >>>> Or perhaps to: >>>> >>>> This document extends the basic set of data communicated with a >>>> Session Initiation Protocol (SIP) based emergency call, as >>>> described in [RFC6443] and [RFC6881] >>>> >>>> Let me know if you feel this change would be helpful. >>> >>> I think the second version would be helpful. >>> >>> >>> [...] >>> >>>> >>>>> -- 3: >>>>> Is there a critical need for the bit about "certain private-use >>>>> situations"? That seems like license for abuse, without more >>>>> elaboration >>>>> about "prexisting relationship" and "privacy issues addressed". >>>> >>>> The reason for that text is to permit re-use of the mechanisms within >>>> private telematics calls between a vehicle and a telematics service >>>> center (which in turn simplifies the use of the mechanisms when such >>>> calls are emergency calls from the telematics service center to a >>>> PSAP). The text appears as an exception to a ban on using the >>>> mechanisms outside of an emergency call, so without it, such use >>>> would be violating the RFC. I thought the text was pretty >>>> restrictive, since it says: >>>> >>>> certain private-use situations where the endpoints >>>> have a preexisting relationship and privacy issues are addressed >>>> within the relationship or do not apply because of it >>>> >>>> If you still feel this text is a "license for abuse" I'd be open to >>>> tightening it, but it seems pretty limited to me. >>> >>> Thanks for the explanation. I can live with what's there. >>> >>> [...] >>> >>>> >>>>> -- 4.1.5: >>>>> Do you intend 24x7 support to be a prerequisite to be a data >>>>> provider? >>>> >>>> It's not within scope of the IETF to make this requirement, but the >>>> expectation is that calls will be processed by mainstream providers >>>> who have 24/7 support for PSAPs. >>> >>> >>> The descriptions says "...information MUST be a URI to a 24/7 support >>> organization..." That sounds like the IETF is making the requirement. >>> >>> I'd be happy to have a non-normative statement that this is expected >>> by the community to be a 24/7 support organization, but the MUST >>> doesn't seem to fit. >>> >>>>> Also, it seems like there are vcard fields that are not useful to >>>>> this >>>>> purpose and might still have privacy implications. Do we really need >>>>> people >>>>> to send everything? >>>> >>>> The text does not mandate which fields to send. It encourages >>>> sending all fields because there are some unusual circumstances where >>>> a seemingly irrelevant field might be useful to a call-taker (e.g., >>>> anniversary might conceivably be useful with a suicidal caller) and >>>> suggests a minimum set. >>> >>> I think there needs to be a balance between "conceivably useful" and >>> "likely to be privacy-sensitive". But IIRC, this discussion is >>> happening separately, isn't it? >>> >>> [...] >>> >>>>> -- 5, list item 1: "The "purpose" parameter also indicates the >>>>> kind of >>>>> data >>>>> (by its MIME subtype) that is available at the URI" >>>>> What happens if the URL points to something other than the indicated >>>>> thing? >>>> >>>> Then the PSAP doesn't get what it expects, and likely will ignore the >>>> retrieved data, and the call will be processed as if the block wasn't >>>> provided at all. The PSAP will likely file a discrepancy report with >>>> the provider, which is done out of band. If the information in the >>>> block is potentially urgent for handling the call, the call-taker or >>>> a supervisor might contact the provider's PSAP support line. >>> >>> That's probably fine, although I wonder if there might be room for >>> guidance that the PSAP shouldn't just load arbitrary data if it gets >>> something unexpected. >>> >>> [...] >>>>> -- 8: >>>>> It might be worth discussing the potential harm done by a malicious >>>>> proxy >>>>> modifying a data element, or a compromised data source return >>>>> incorrect >>>>> information when dereferencing a URL. >>>> >>>> If an element in the call path is compromised and under the control >>>> of an attacker, it can wreak havoc, but this is generally true for >>>> any system that isn't using end-to-end protection, and even then is >>>> true if an endpoint is compromised. I'm not sure what would be >>>> helpful to say about this in the Security Considerations section. >>> >>> I'm not going to push the point--but keep in mind the "compromised >>> data source" case involves something _not_ in the call path. >>> >>> [...] >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Sun Oct 4 14:12:24 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30FE1A6F9C; Sun, 4 Oct 2015 14:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jP75zCGEu9XN; Sun, 4 Oct 2015 14:12:18 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB501A6F99; Sun, 4 Oct 2015 14:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1443993138; x=1475529138; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=oqPw4eQjnVCHz+ZKIHpfQy58NLUiq8sWyqz0lHq/Tyw=; b=kwCN9S3KDCD0wi3L0qpKGo5r+1at4yUC6VEMwDeIAr3pemlp+ZEt6rRh zWBuoQWmQelKTm4cTiHUTlc2LLTK/1hL8XnwB0skUPGwX7x5aXKGWewtB QNTOm5PdG555glFCfEjKs7vByc6JKKrDk6BXxQ2CXyIyXtqwlH8/3mQqC E=; X-IronPort-AV: E=McAfee;i="5700,7163,7944"; a="99115755" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Oct 2015 14:12:17 -0700 X-IronPort-AV: E=Sophos;i="5.17,635,1437462000"; d="scan'208";a="1011307192" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Oct 2015 14:12:16 -0700 Received: from [100.44.209.138] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 4 Oct 2015 14:12:07 -0700 Message-ID: In-Reply-To: <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> X-Mailer: Eudora for Mac OS X Date: Sun, 4 Oct 2015 14:12:10 -0700 To: Ben Campbell , Randall Gellens From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (10.85.0.81) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org, The IESG Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 21:12:20 -0000 Hi Ben, At 4:38 PM -0500 10/2/15, Ben Campbell wrote: > Oops, I just ran across this going back over old messages. I don't > think I responded; apologies for that. Comments inline. I deleted > sections that don't seem to need further discussion. > > Thanks! > > Ben. > > On 13 Sep 2015, at 18:51, Randall Gellens wrote: > > [...] > >>>> >>> [Edit: I asked a question below about what happens if you dereference a >>> block, and find the URL points to something other than what you expected. >>> On reflection, I should expand that to ask how dereferencing errors >>> should be handled in general.] >> >> In general, since this is an emergency call, we want the call to >> go through even if there are errors. It's better that the call go >> through with some data blocks missing or unusable than for the >> call to fail. > > That makes sense--is there any text that says that? If not, it > might be worth adding. Seems reasonable. I added the following at the end of Section 6 (which introduces the transport mechanisms): Note that, as with any mechanism, failures are possible. For example, a block (provided by value or by reference) might not be the type indicated by the "purpose" parameter, or might be badly formed, etc. The general principle that applies to emergency calls is that it is more important for the call to go through than for for everything to be correct. Thus, most PSAPs will process a call if at all possible, even if data is missing or other failures occur. > > [...] > >>>> This draft implicitly assumes that the emergency calls are signaled with >>> SIP. I don't dispute that assumption, but I think it should it's worth a >>> paragraph stating it explicitly. >> >> The Introduction says: >> >> This document extends the basic set of data communicated with an IP- >> based emergency call, as described in [RFC6443] and [RFC6881] >> >> Both those RFCs are explicitly SIP-based. However, I'd be happy >> to change the text from "IP-based" to "SIP-based" if people feel >> it would add clarity. E.g., to: >> >> This document extends the basic set of data communicated with a SIP- >> based emergency call, as described in [RFC6443] and [RFC6881] >> >> Or perhaps to: >> >> This document extends the basic set of data communicated with a >> Session Initiation Protocol (SIP) based emergency call, as >> described in [RFC6443] and [RFC6881] >> >> Let me know if you feel this change would be helpful. > > I think the second version would be helpful. OK, added. ... >> >>> -- 4.1.5: >>> Do you intend 24x7 support to be a prerequisite to be a data >>> provider? >> >> It's not within scope of the IETF to make this requirement, but >> the expectation is that calls will be processed by mainstream >> providers who have 24/7 support for PSAPs. > > > The descriptions says "...information MUST be a URI to a 24/7 > support organization..." That sounds like the IETF is making the > requirement. > > I'd be happy to have a non-normative statement that this is > expected by the community to be a 24/7 support organization, but > the MUST doesn't seem to fit. I changed the "MUST" to "is expected to be". ... > >>> -- 5, list item 1: "The "purpose" parameter also indicates the kind of >>> data >>> (by its MIME subtype) that is available at the URI" >>> What happens if the URL points to something other than the indicated >>> thing? >> >> Then the PSAP doesn't get what it expects, and likely will ignore >> the retrieved data, and the call will be processed as if the block >> wasn't provided at all. The PSAP will likely file a discrepancy >> report with the provider, which is done out of band. If the >> information in the block is potentially urgent for handling the >> call, the call-taker or a supervisor might contact the provider's >> PSAP support line. > > That's probably fine, although I wonder if there might be room for > guidance that the PSAP shouldn't just load arbitrary data if it > gets something unexpected. The document already says A PSAP or emergency responder is able to examine the type of data provided and selectively access the data it is interested in I think that makes the point that PSAPs will only access the data they decide they want, and hence, if data turns out to be of a different type, they will likely ignore it. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Vital papers will demonstrate their vitality by spontaneously moving from where you left them to where you can't find them. From nobody Sun Oct 4 14:14:42 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331B01A6F9F; Sun, 4 Oct 2015 14:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.711 X-Spam-Level: X-Spam-Status: No, score=-6.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvLERcABZXPO; Sun, 4 Oct 2015 14:14:38 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B501A6F9C; Sun, 4 Oct 2015 14:14:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1443993278; x=1475529278; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version:content-transfer-encoding; bh=MyNFsJYNUEWrnnKAAxaSPjXFt8nU+tPAUMMFdshCLdc=; b=gxcsQpA/BmnkY+GqZsptEf1EAOdl1i8l9K02QG2+nfK6G218vwzO3T5L KuTs4r3y1WTycO7gByhCS5LW15GI6S3VMprE8ehF/3g2oO6sqdYC5tqCd XSfmYNsI89aTvTy9pEKeA/5GXfVsL5RgCyaVTdnfYUqAi8vz5rvTVzxY5 M=; X-IronPort-AV: E=McAfee;i="5700,7163,7944"; a="234954319" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Oct 2015 14:14:37 -0700 X-IronPort-AV: E=Sophos;i="5.17,634,1437462000"; d="scan'208";a="1011851875" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 04 Oct 2015 14:14:37 -0700 Received: from [100.44.209.138] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 4 Oct 2015 14:14:30 -0700 Message-ID: In-Reply-To: <560FC5AF.3090302@omnitor.se> References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> <560FC5AF.3090302@omnitor.se> X-Mailer: Eudora for Mac OS X Date: Sun, 4 Oct 2015 14:14:33 -0700 To: Gunnar =?iso-8859-1?Q?Hellstr=F6m?= , Ben Campbell From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01B.na.qualcomm.com (10.85.0.82) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 21:14:39 -0000 Hi Gunnar, At 2:10 PM +0200 10/3/15, Gunnar Hellstr=F6m wrote: > A comment on the 24/7 discussion on section 4.1.5: > Relay services are supposed to be data providers. > Sadly, the deployment of relay services is very=20 > slow in some regions, and if they exist, they=20 > often operate limited hours. > This is of course a problem when making=20 > emergency calls, but the wording in 4.1.5=20 > should not discourage relay services from=20 > registering and providing data because they=20 > currently have limited opening hours. The text in question says "When provided by a=20 service provider or an access network provider"=20 so I think small relay operations are OK, and=20 anyway, the MUST was changed to "is expected to=20 be". > ---------------- > Another issue around relay services: It would=20 > be good to get a URI that can be used for=20 > bridging in the relay service together with a=20 > call-back. This is because the relay service=20 > might have been invoked in a way so that the=20 > call-back address to the original caller does=20 > not automatically invoke the relay service.=20 > None of the provided data seem to specify that=20 > kind of URI. This should be done in SLIM, not here. -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Political T.V. commercials prove one thing: some candidates can tell all their good points and qualifications in just 30 seconds. From nobody Sun Oct 4 14:22:27 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65A911A86EE; Sun, 4 Oct 2015 14:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnsY5btrbYa8; Sun, 4 Oct 2015 14:22:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0FB21A86DF; Sun, 4 Oct 2015 14:22:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151004212224.4738.33644.idtracker@ietfa.amsl.com> Date: Sun, 04 Oct 2015 14:22:24 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-36.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 21:22:26 -0000 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 : Additional Data Related to an Emergency Call Authors : Randall Gellens Brian Rosen Hannes Tschofenig Roger Marshall James Winterbottom Filename : draft-ietf-ecrit-additional-data-36.txt Pages : 112 Date : 2015-10-04 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller or the location which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much as possible of the information described here using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-additional-data-36 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-36 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 4 15:00:04 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165521B2D89; Sun, 4 Oct 2015 15:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjofYhyHDoTi; Sun, 4 Oct 2015 14:59:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9301B2D86; Sun, 4 Oct 2015 14:59:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151004215959.22015.4576.idtracker@ietfa.amsl.com> Date: Sun, 04 Oct 2015 14:59:59 -0700 Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org Subject: [Ecrit] Stephen Farrell's No Objection on draft-ietf-ecrit-additional-data-36: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 22:00:01 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-ecrit-additional-data-36: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for handling my discuss points. -35 handled most of the stuff below just fine but I left the comments there. I didn't check -36 for that. - abstract: the "or by reference" point is made twice in the abstract - intro: floor plans? HVAC status? really? Why not contact lists? proximity of friends? That (or inferring as much) seems to me to be going too far, if applied to all calls. I'd say just saying that this could be extended in future by other standards-track specifications is enough. (See also discuss points above) - intro: Wedding anniversary? That's surely not relevant to a PSAP. - figure 5: "prison" is out of context here, I'd suggest deleting it. If not, why not add hospital, power station and many other kinds of building? There may be some country specific issue or technical here, but labelling that with "prison" seems inappropriate to me. - 4.3.8: sorry I don't get the privacy argument, can you try explain it to me? (I didn't know it was possible to tempt an implementation, so the language there could be improved for sure:-) - section 5: good that this is HTTPS only. I think provisioning the PKI for such a thing is easily done these days and is rightly not optional. It might be useful to say that TLS here needs to follow BCP195. I agree with the earlier comment that you should be clear as to when mutually authenticated TLS is required. The secdir review [2] also raised similar issues and it'd be good to see responses to that too. (Yes, that review only arrived today so it's entirely reasonable to not have responded so far.) [2] https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html - section 8: the sizes of the various additional data items here could be characteristic and leak value information regardless of TLS or not-TLS - perhaps add a warning that these may enable relatively simple traffic analysis. And wouldn't it be nice if someone had done the analysis of this potential vulnerability? This is btw a real issue - recall that avatar icon image size was usable to identify 30+% of contacts in one social network even over TLS, but before the provider canonicalised the avatar image sizes. - Thanks for section 9. Good job. From nobody Sun Oct 4 15:10:58 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D7D1B2DA2 for ; Sun, 4 Oct 2015 15:10:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bkyKdj8J8kDe for ; Sun, 4 Oct 2015 15:10:56 -0700 (PDT) Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809161B2DA8 for ; Sun, 4 Oct 2015 15:10:54 -0700 (PDT) X-Halon-ID: c569378c-6ae4-11e5-98bf-0050569116f7 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-03.atm.binero.net (Halon Mail Gateway) with ESMTPSA; Mon, 5 Oct 2015 00:10:50 +0200 (CEST) To: Randall Gellens , Ben Campbell References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> <560FC5AF.3090302@omnitor.se> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <5611A3E8.1090100@omnitor.se> Date: Mon, 5 Oct 2015 00:10:48 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, The IESG , draft-ietf-ecrit-additional-data.shepherd@ietf.org, ecrit-chairs@ietf.org Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2015 22:10:57 -0000 Den 2015-10-04 kl. 23:14, skrev Randall Gellens: > Hi Gunnar, > > At 2:10 PM +0200 10/3/15, Gunnar Hellström wrote: > >> A comment on the 24/7 discussion on section 4.1.5: >> Relay services are supposed to be data providers. >> Sadly, the deployment of relay services is very slow in some >> regions, and if they exist, they often operate limited hours. >> This is of course a problem when making emergency calls, but the >> wording in 4.1.5 should not discourage relay services from >> registering and providing data because they currently have limited >> opening hours. > > The text in question says "When provided by a service provider or an > access network provider" so I think small relay operations are OK, and > anyway, the MUST was changed to "is expected to be". OK ,fine, accepted. > > >> ---------------- >> Another issue around relay services: It would be good to get a URI >> that can be used for bridging in the relay service together with a >> call-back. This is because the relay service might have been invoked >> in a way so that the call-back address to the original caller does >> not automatically invoke the relay service. None of the provided data >> seem to specify that kind of URI. > > This should be done in SLIM, not here. Yes, at least not here, since the intention here seems to not be to provide operational data in Additional-Data. > > > /Gunnar From nobody Sun Oct 4 21:56:10 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FDC1B4401; Sun, 4 Oct 2015 21:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJtpOgyI0I2P; Sun, 4 Oct 2015 21:56:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA651B4400; Sun, 4 Oct 2015 21:56:06 -0700 (PDT) Received: from [10.0.1.9] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t954u445095130 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 4 Oct 2015 23:56:04 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.9] From: "Ben Campbell" To: "Randall Gellens" Date: Sun, 04 Oct 2015 23:56:03 -0500 Message-ID: In-Reply-To: References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.2r5141) Archived-At: Cc: draft-ietf-ecrit-additional-data@ietf.org, ecrit@ietf.org, draft-ietf-ecrit-additional-data.ad@ietf.org, ecrit-chairs@ietf.org, draft-ietf-ecrit-additional-data.shepherd@ietf.org, The IESG Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 04:56:07 -0000 On 4 Oct 2015, at 16:12, Randall Gellens wrote: > Hi Ben, > > At 4:38 PM -0500 10/2/15, Ben Campbell wrote: > >> Oops, I just ran across this going back over old messages. I don't >> think I responded; apologies for that. Comments inline. I deleted >> sections that don't seem to need further discussion. >> >> Thanks! >> >> Ben. >> >> On 13 Sep 2015, at 18:51, Randall Gellens wrote: >> >> [...] >> >>>>> >>>> [Edit: I asked a question below about what happens if you >>>> dereference a >>>> block, and find the URL points to something other than what you >>>> expected. >>>> On reflection, I should expand that to ask how dereferencing >>>> errors >>>> should be handled in general.] >>> >>> In general, since this is an emergency call, we want the call to go >>> through even if there are errors. It's better that the call go >>> through with some data blocks missing or unusable than for the call >>> to fail. >> >> That makes sense--is there any text that says that? If not, it might >> be worth adding. > > Seems reasonable. I added the following at the end of Section 6 > (which introduces the transport mechanisms): > > Note that, as with any mechanism, failures are possible. For > example, a block (provided by value or by reference) might not be the > type indicated by the "purpose" parameter, or might be badly formed, > etc. The general principle that applies to emergency calls is that > it is more important for the call to go through than for for > everything to be correct. Thus, most PSAPs will process a call if at > all possible, even if data is missing or other failures occur. > > That works for me. [...] >> >>>> -- 5, list item 1: "The "purpose" parameter also indicates the kind >>>> of >>>> data >>>> (by its MIME subtype) that is available at the URI" >>>> What happens if the URL points to something other than the >>>> indicated >>>> thing? >>> >>> Then the PSAP doesn't get what it expects, and likely will ignore >>> the retrieved data, and the call will be processed as if the block >>> wasn't provided at all. The PSAP will likely file a discrepancy >>> report with the provider, which is done out of band. If the >>> information in the block is potentially urgent for handling the >>> call, the call-taker or a supervisor might contact the provider's >>> PSAP support line. >> >> That's probably fine, although I wonder if there might be room for >> guidance that the PSAP shouldn't just load arbitrary data if it gets >> something unexpected. > > The document already says > > A PSAP or emergency responder is able to examine the > type of data provided and selectively access the data it is > interested in > > I think that makes the point that PSAPs will only access the data they > decide they want, and hence, if data turns out to be of a different > type, they will likely ignore it. Ah, sorry, I forgot about that. I think that covers things well enough. Ben. From nobody Mon Oct 5 08:48:15 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA0581B31C7 for ; Mon, 5 Oct 2015 08:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VMOCKdOS9uyX for ; Mon, 5 Oct 2015 08:48:09 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDAC1B31BF for ; Mon, 5 Oct 2015 08:48:08 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id t95Fm7Pu028281; Mon, 5 Oct 2015 11:48:07 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 1xbr160de4-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 05 Oct 2015 11:48:07 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.189]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0158.001; Mon, 5 Oct 2015 11:48:06 -0400 From: "Rosen, Brian" To: =?Windows-1252?Q?Gunnar_Hellstr=F6m?= Thread-Topic: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) Thread-Index: AQHQ/4U6vmt7j2+lfE6w77Iv77N7yA== Date: Mon, 5 Oct 2015 15:48:06 +0000 Message-ID: <33C30179-E973-4FE8-BC37-B110A93F2A58@neustar.biz> References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> <560FC5AF.3090302@omnitor.se> <561023C2.3080507@alum.mit.edu> <56104F6F.1010301@omnitor.se> In-Reply-To: <56104F6F.1010301@omnitor.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [156.154.7.131] Content-Type: text/plain; charset="Windows-1252" Content-ID: <08DF147AC8B7444DBC6CA49515694868@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-10-05_06:2015-10-05,2015-10-05,1970-01-01 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 15:48:12 -0000 What is the PSAP supposed to do with this URL? Create a bridge and bridge = in the URL? Brian > On Oct 3, 2015, at 4:58 PM, Gunnar Hellstr=F6m wrote: >=20 > Den 2015-10-03 kl. 20:51, skrev Paul Kyzivat: >> On 10/3/15 8:10 AM, Gunnar Hellstr=F6m wrote: >>> A comment on the 24/7 discussion on section 4.1.5: >>> Relay services are supposed to be data providers. >>> Sadly, the deployment of relay services is very slow in some regions, >>> and if they exist, they often operate limited hours. >>> This is of course a problem when making emergency calls, but the wordin= g >>> in 4.1.5 should not discourage relay services from registering and >>> providing data because they currently have limited opening hours. >>> ---------------- >>> Another issue around relay services: It would be good to get a URI that >>> can be used for bridging in the relay service together with a call-back= . >>> This is because the relay service might have been invoked in a way so >>> that the call-back address to the original caller does not automaticall= y >>> invoke the relay service. None of the provided data seem to specify tha= t >>> kind of URI. >>> ---------------- >>=20 >> If the relay service was included in such a way that callbacks don't bri= ng it back in, then having the URL of the relay service won't necessarily m= ean that the entity doing the callback will be authorized to obtain relay s= ervices on the callback call. >>=20 >> I don't see a good way to solve that except for the relay service to be = authorized based on whichever end of the call desires/needs the relay servi= ce. > Yes, that would be included in a recommendation for how to use a URL fiel= d in Additional-Data. > A region could have requirements that the relay services who are register= ed as data providers also authorize calls from the region. > But it would be equally good if you can propose another field to convey s= uch an URL in. It does not seem to be the intention of Additional-Data to p= rovide operational information. >>=20 >> Thanks, >> Paul >>=20 >>> /Gunnar Hellstrom >>>=20 >>> Den 2015-10-02 kl. 23:38, skrev Ben Campbell: >>>> Oops, I just ran across this going back over old messages. I don't >>>> think I responded; apologies for that. Comments inline. I deleted >>>> sections that don't seem to need further discussion. >>>>=20 >>>> Thanks! >>>>=20 >>>> Ben. >>>>=20 >>>> On 13 Sep 2015, at 18:51, Randall Gellens wrote: >>>>=20 >>>> [...] >>>>=20 >>>>>>>=20 >>>>>> [Edit: I asked a question below about what happens if you dereferenc= e a >>>>>> block, and find the URL points to something other than what you >>>>>> expected. >>>>>> On reflection, I should expand that to ask how dereferencing errors >>>>>> should be handled in general.] >>>>>=20 >>>>> In general, since this is an emergency call, we want the call to go >>>>> through even if there are errors. It's better that the call go >>>>> through with some data blocks missing or unusable than for the call >>>>> to fail. >>>>=20 >>>> That makes sense--is there any text that says that? If not, it might >>>> be worth adding. >>>>=20 >>>> [...] >>>>=20 >>>>>>> This draft implicitly assumes that the emergency calls are signaled >>>>>>> with >>>>>> SIP. I don't dispute that assumption, but I think it should it's >>>>>> worth a >>>>>> paragraph stating it explicitly. >>>>>=20 >>>>> The Introduction says: >>>>>=20 >>>>> This document extends the basic set of data communicated with an IP- >>>>> based emergency call, as described in [RFC6443] and [RFC6881] >>>>>=20 >>>>> Both those RFCs are explicitly SIP-based. However, I'd be happy to >>>>> change the text from "IP-based" to "SIP-based" if people feel it >>>>> would add clarity. E.g., to: >>>>>=20 >>>>> This document extends the basic set of data communicated with a SIP- >>>>> based emergency call, as described in [RFC6443] and [RFC6881] >>>>>=20 >>>>> Or perhaps to: >>>>>=20 >>>>> This document extends the basic set of data communicated with a >>>>> Session Initiation Protocol (SIP) based emergency call, as >>>>> described in [RFC6443] and [RFC6881] >>>>>=20 >>>>> Let me know if you feel this change would be helpful. >>>>=20 >>>> I think the second version would be helpful. >>>>=20 >>>>=20 >>>> [...] >>>>=20 >>>>>=20 >>>>>> -- 3: >>>>>> Is there a critical need for the bit about "certain private-use >>>>>> situations"? That seems like license for abuse, without more >>>>>> elaboration >>>>>> about "prexisting relationship" and "privacy issues addressed". >>>>>=20 >>>>> The reason for that text is to permit re-use of the mechanisms within >>>>> private telematics calls between a vehicle and a telematics service >>>>> center (which in turn simplifies the use of the mechanisms when such >>>>> calls are emergency calls from the telematics service center to a >>>>> PSAP). The text appears as an exception to a ban on using the >>>>> mechanisms outside of an emergency call, so without it, such use >>>>> would be violating the RFC. I thought the text was pretty >>>>> restrictive, since it says: >>>>>=20 >>>>> certain private-use situations where the endpoints >>>>> have a preexisting relationship and privacy issues are addressed >>>>> within the relationship or do not apply because of it >>>>>=20 >>>>> If you still feel this text is a "license for abuse" I'd be open to >>>>> tightening it, but it seems pretty limited to me. >>>>=20 >>>> Thanks for the explanation. I can live with what's there. >>>>=20 >>>> [...] >>>>=20 >>>>>=20 >>>>>> -- 4.1.5: >>>>>> Do you intend 24x7 support to be a prerequisite to be a data >>>>>> provider? >>>>>=20 >>>>> It's not within scope of the IETF to make this requirement, but the >>>>> expectation is that calls will be processed by mainstream providers >>>>> who have 24/7 support for PSAPs. >>>>=20 >>>>=20 >>>> The descriptions says "...information MUST be a URI to a 24/7 support >>>> organization..." That sounds like the IETF is making the requirement. >>>>=20 >>>> I'd be happy to have a non-normative statement that this is expected >>>> by the community to be a 24/7 support organization, but the MUST >>>> doesn't seem to fit. >>>>=20 >>>>>> Also, it seems like there are vcard fields that are not useful to th= is >>>>>> purpose and might still have privacy implications. Do we really need >>>>>> people >>>>>> to send everything? >>>>>=20 >>>>> The text does not mandate which fields to send. It encourages >>>>> sending all fields because there are some unusual circumstances where >>>>> a seemingly irrelevant field might be useful to a call-taker (e.g., >>>>> anniversary might conceivably be useful with a suicidal caller) and >>>>> suggests a minimum set. >>>>=20 >>>> I think there needs to be a balance between "conceivably useful" and >>>> "likely to be privacy-sensitive". But IIRC, this discussion is >>>> happening separately, isn't it? >>>>=20 >>>> [...] >>>>=20 >>>>>> -- 5, list item 1: "The "purpose" parameter also indicates the kind = of >>>>>> data >>>>>> (by its MIME subtype) that is available at the URI" >>>>>> What happens if the URL points to something other than the indicated >>>>>> thing? >>>>>=20 >>>>> Then the PSAP doesn't get what it expects, and likely will ignore the >>>>> retrieved data, and the call will be processed as if the block wasn't >>>>> provided at all. The PSAP will likely file a discrepancy report with >>>>> the provider, which is done out of band. If the information in the >>>>> block is potentially urgent for handling the call, the call-taker or >>>>> a supervisor might contact the provider's PSAP support line. >>>>=20 >>>> That's probably fine, although I wonder if there might be room for >>>> guidance that the PSAP shouldn't just load arbitrary data if it gets >>>> something unexpected. >>>>=20 >>>> [...] >>>>>> -- 8: >>>>>> It might be worth discussing the potential harm done by a malicious >>>>>> proxy >>>>>> modifying a data element, or a compromised data source return incorr= ect >>>>>> information when dereferencing a URL. >>>>>=20 >>>>> If an element in the call path is compromised and under the control >>>>> of an attacker, it can wreak havoc, but this is generally true for >>>>> any system that isn't using end-to-end protection, and even then is >>>>> true if an endpoint is compromised. I'm not sure what would be >>>>> helpful to say about this in the Security Considerations section. >>>>=20 >>>> I'm not going to push the point--but keep in mind the "compromised >>>> data source" case involves something _not_ in the call path. >>>>=20 >>>> [...] >>>>=20 >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit From nobody Mon Oct 5 10:13:14 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B9211ACE9B for ; Mon, 5 Oct 2015 10:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H9w3dIOyEApw for ; Mon, 5 Oct 2015 10:13:11 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF79E1A1B0B for ; Mon, 5 Oct 2015 10:13:10 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-07v.sys.comcast.net with comcast id RV6L1r00326dK1R01VDAEE; Mon, 05 Oct 2015 17:13:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id RVD91r00A3Ge9ey01VD9CR; Mon, 05 Oct 2015 17:13:09 +0000 To: ecrit@ietf.org References: <20150901144212.18261.13357.idtracker@ietfa.amsl.com> <13A6EAEC-97BE-43B3-B0D8-2056385A8EB6@nostrum.com> <560FC5AF.3090302@omnitor.se> <561023C2.3080507@alum.mit.edu> <56104F6F.1010301@omnitor.se> <33C30179-E973-4FE8-BC37-B110A93F2A58@neustar.biz> From: Paul Kyzivat Message-ID: <5612AFA4.5000803@alum.mit.edu> Date: Mon, 5 Oct 2015 13:13:08 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <33C30179-E973-4FE8-BC37-B110A93F2A58@neustar.biz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1444065190; bh=94UzxxW15nBXwqnOA1VmYb1LMOd0JebhqlxvGbdpL8Y=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=oGTAEyoTMwdEzE2KmTwqweI2q/xD8X1J1oNg2+0exFBCyVsIk/b6MgErbaUJ+o/BT /eHqojAZUoHf6lzmUZiaJIKIY5fmtIlvSrI5wm2AlD6qazjW1mYmyUOvSuokAMrYaF VxP1nDfEl6y6CqN7TjeJ2Bv2PkCDOxB04fjXN9brw7UFy5DapdFFT6mGWh/GwSikw7 ljkPNuPf3fZYbzq9qpP9r4HN9WohO0oYt5FTsekhu303DZZ6aL0Jls+8TBzA5+LqxU zSp272nSbajzfz2slbz9J/ltjfRSp8Q5cF8Hxx4foJjOmZqvKUNUkEaE0Xug0J8pT5 fBr5Al1Bzguig== Archived-At: Subject: Re: [Ecrit] Ben Campbell's Yes on draft-ietf-ecrit-additional-data-34: (with COMMENT) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2015 17:13:13 -0000 On 10/5/15 11:48 AM, Rosen, Brian wrote: > What is the PSAP supposed to do with this URL? Create a bridge and bridge in the URL? This all makes little sense to me. It seems there are two cases: 1) on original call, some agent acting for the caller bridged in a relay. 2) on the original call, some agent acting for the callee (the PSAP) bridged in a relay. ISTM that in the case of a callback, the relay should again be bridged in by an agent for the end that got the relay originally. It makes little sense to me, when the caller originally bridged in the relay, for the PSAP to attempt to bridge in the same relay on a callback. So in case (1), making a callback call to the callback URI (probably the contact from the original call) should implicitly cause the relay to be brought back in. Hence there would be no need to pass a URI for the relay to the PSAP. Thanks, Paul > Brian >> On Oct 3, 2015, at 4:58 PM, Gunnar Hellström wrote: >> >> Den 2015-10-03 kl. 20:51, skrev Paul Kyzivat: >>> On 10/3/15 8:10 AM, Gunnar Hellström wrote: >>>> A comment on the 24/7 discussion on section 4.1.5: >>>> Relay services are supposed to be data providers. >>>> Sadly, the deployment of relay services is very slow in some regions, >>>> and if they exist, they often operate limited hours. >>>> This is of course a problem when making emergency calls, but the wording >>>> in 4.1.5 should not discourage relay services from registering and >>>> providing data because they currently have limited opening hours. >>>> ---------------- >>>> Another issue around relay services: It would be good to get a URI that >>>> can be used for bridging in the relay service together with a call-back. >>>> This is because the relay service might have been invoked in a way so >>>> that the call-back address to the original caller does not automatically >>>> invoke the relay service. None of the provided data seem to specify that >>>> kind of URI. >>>> ---------------- >>> >>> If the relay service was included in such a way that callbacks don't bring it back in, then having the URL of the relay service won't necessarily mean that the entity doing the callback will be authorized to obtain relay services on the callback call. >>> >>> I don't see a good way to solve that except for the relay service to be authorized based on whichever end of the call desires/needs the relay service. >> Yes, that would be included in a recommendation for how to use a URL field in Additional-Data. >> A region could have requirements that the relay services who are registered as data providers also authorize calls from the region. >> But it would be equally good if you can propose another field to convey such an URL in. It does not seem to be the intention of Additional-Data to provide operational information. >>> >>> Thanks, >>> Paul >>> >>>> /Gunnar Hellstrom >>>> >>>> Den 2015-10-02 kl. 23:38, skrev Ben Campbell: >>>>> Oops, I just ran across this going back over old messages. I don't >>>>> think I responded; apologies for that. Comments inline. I deleted >>>>> sections that don't seem to need further discussion. >>>>> >>>>> Thanks! >>>>> >>>>> Ben. >>>>> >>>>> On 13 Sep 2015, at 18:51, Randall Gellens wrote: >>>>> >>>>> [...] >>>>> >>>>>>>> >>>>>>> [Edit: I asked a question below about what happens if you dereference a >>>>>>> block, and find the URL points to something other than what you >>>>>>> expected. >>>>>>> On reflection, I should expand that to ask how dereferencing errors >>>>>>> should be handled in general.] >>>>>> >>>>>> In general, since this is an emergency call, we want the call to go >>>>>> through even if there are errors. It's better that the call go >>>>>> through with some data blocks missing or unusable than for the call >>>>>> to fail. >>>>> >>>>> That makes sense--is there any text that says that? If not, it might >>>>> be worth adding. >>>>> >>>>> [...] >>>>> >>>>>>>> This draft implicitly assumes that the emergency calls are signaled >>>>>>>> with >>>>>>> SIP. I don't dispute that assumption, but I think it should it's >>>>>>> worth a >>>>>>> paragraph stating it explicitly. >>>>>> >>>>>> The Introduction says: >>>>>> >>>>>> This document extends the basic set of data communicated with an IP- >>>>>> based emergency call, as described in [RFC6443] and [RFC6881] >>>>>> >>>>>> Both those RFCs are explicitly SIP-based. However, I'd be happy to >>>>>> change the text from "IP-based" to "SIP-based" if people feel it >>>>>> would add clarity. E.g., to: >>>>>> >>>>>> This document extends the basic set of data communicated with a SIP- >>>>>> based emergency call, as described in [RFC6443] and [RFC6881] >>>>>> >>>>>> Or perhaps to: >>>>>> >>>>>> This document extends the basic set of data communicated with a >>>>>> Session Initiation Protocol (SIP) based emergency call, as >>>>>> described in [RFC6443] and [RFC6881] >>>>>> >>>>>> Let me know if you feel this change would be helpful. >>>>> >>>>> I think the second version would be helpful. >>>>> >>>>> >>>>> [...] >>>>> >>>>>> >>>>>>> -- 3: >>>>>>> Is there a critical need for the bit about "certain private-use >>>>>>> situations"? That seems like license for abuse, without more >>>>>>> elaboration >>>>>>> about "prexisting relationship" and "privacy issues addressed". >>>>>> >>>>>> The reason for that text is to permit re-use of the mechanisms within >>>>>> private telematics calls between a vehicle and a telematics service >>>>>> center (which in turn simplifies the use of the mechanisms when such >>>>>> calls are emergency calls from the telematics service center to a >>>>>> PSAP). The text appears as an exception to a ban on using the >>>>>> mechanisms outside of an emergency call, so without it, such use >>>>>> would be violating the RFC. I thought the text was pretty >>>>>> restrictive, since it says: >>>>>> >>>>>> certain private-use situations where the endpoints >>>>>> have a preexisting relationship and privacy issues are addressed >>>>>> within the relationship or do not apply because of it >>>>>> >>>>>> If you still feel this text is a "license for abuse" I'd be open to >>>>>> tightening it, but it seems pretty limited to me. >>>>> >>>>> Thanks for the explanation. I can live with what's there. >>>>> >>>>> [...] >>>>> >>>>>> >>>>>>> -- 4.1.5: >>>>>>> Do you intend 24x7 support to be a prerequisite to be a data >>>>>>> provider? >>>>>> >>>>>> It's not within scope of the IETF to make this requirement, but the >>>>>> expectation is that calls will be processed by mainstream providers >>>>>> who have 24/7 support for PSAPs. >>>>> >>>>> >>>>> The descriptions says "...information MUST be a URI to a 24/7 support >>>>> organization..." That sounds like the IETF is making the requirement. >>>>> >>>>> I'd be happy to have a non-normative statement that this is expected >>>>> by the community to be a 24/7 support organization, but the MUST >>>>> doesn't seem to fit. >>>>> >>>>>>> Also, it seems like there are vcard fields that are not useful to this >>>>>>> purpose and might still have privacy implications. Do we really need >>>>>>> people >>>>>>> to send everything? >>>>>> >>>>>> The text does not mandate which fields to send. It encourages >>>>>> sending all fields because there are some unusual circumstances where >>>>>> a seemingly irrelevant field might be useful to a call-taker (e.g., >>>>>> anniversary might conceivably be useful with a suicidal caller) and >>>>>> suggests a minimum set. >>>>> >>>>> I think there needs to be a balance between "conceivably useful" and >>>>> "likely to be privacy-sensitive". But IIRC, this discussion is >>>>> happening separately, isn't it? >>>>> >>>>> [...] >>>>> >>>>>>> -- 5, list item 1: "The "purpose" parameter also indicates the kind of >>>>>>> data >>>>>>> (by its MIME subtype) that is available at the URI" >>>>>>> What happens if the URL points to something other than the indicated >>>>>>> thing? >>>>>> >>>>>> Then the PSAP doesn't get what it expects, and likely will ignore the >>>>>> retrieved data, and the call will be processed as if the block wasn't >>>>>> provided at all. The PSAP will likely file a discrepancy report with >>>>>> the provider, which is done out of band. If the information in the >>>>>> block is potentially urgent for handling the call, the call-taker or >>>>>> a supervisor might contact the provider's PSAP support line. >>>>> >>>>> That's probably fine, although I wonder if there might be room for >>>>> guidance that the PSAP shouldn't just load arbitrary data if it gets >>>>> something unexpected. >>>>> >>>>> [...] >>>>>>> -- 8: >>>>>>> It might be worth discussing the potential harm done by a malicious >>>>>>> proxy >>>>>>> modifying a data element, or a compromised data source return incorrect >>>>>>> information when dereferencing a URL. >>>>>> >>>>>> If an element in the call path is compromised and under the control >>>>>> of an attacker, it can wreak havoc, but this is generally true for >>>>>> any system that isn't using end-to-end protection, and even then is >>>>>> true if an endpoint is compromised. I'm not sure what would be >>>>>> helpful to say about this in the Security Considerations section. >>>>> >>>>> I'm not going to push the point--but keep in mind the "compromised >>>>> data source" case involves something _not_ in the call path. >>>>> >>>>> [...] >>>>> >>>>> _______________________________________________ >>>>> Ecrit mailing list >>>>> Ecrit@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>>> _______________________________________________ >>>> Ecrit mailing list >>>> Ecrit@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ecrit >>>> >>> >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > From nobody Mon Oct 12 00:56:32 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F95A1A6F9E; Mon, 12 Oct 2015 00:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_kN4L2Sj5dA; Mon, 12 Oct 2015 00:56:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5497F1A8714; Mon, 12 Oct 2015 00:55:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.4.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151012075503.19351.46739.idtracker@ietfa.amsl.com> Date: Mon, 12 Oct 2015 00:55:03 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-additional-data-37.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 07:56:29 -0000 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 : Additional Data Related to an Emergency Call Authors : Randall Gellens Brian Rosen Hannes Tschofenig Roger Marshall James Winterbottom Filename : draft-ietf-ecrit-additional-data-37.txt Pages : 112 Date : 2015-10-12 Abstract: When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller or the location which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much as possible of the information described here using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-additional-data-37 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-additional-data-37 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 12 09:52:53 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF091A88D5; Mon, 12 Oct 2015 09:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0mY5UD-Hs1e; Mon, 12 Oct 2015 09:52:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9F31A88FD; Mon, 12 Oct 2015 09:52:48 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.5.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151012165248.3598.26790.idtracker@ietfa.amsl.com> Date: Mon, 12 Oct 2015 09:52:48 -0700 Archived-At: Cc: ecrit chair , ecrit mailing list , RFC Editor Subject: [Ecrit] Protocol Action: 'Additional Data Related to an Emergency Call' to Proposed Standard (draft-ietf-ecrit-additional-data-37.txt) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2015 16:52:52 -0000 The IESG has approved the following document: - 'Additional Data Related to an Emergency Call' (draft-ietf-ecrit-additional-data-37.txt) as Proposed Standard This document is the product of the Emergency Context Resolution with Internet Technologies Working Group. The IESG contact persons are Ben Campbell, Barry Leiba and Alissa Cooper. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/ Technical Summary > When an emergency call is sent to a Public Safety Answering Point > (PSAP), the device that sends it, as well as any application service > provider in the path of the call, or access network provider through > which the call originated may have information about the call, the > caller or the location which the PSAP may be able to use. > > This document describes data structures and a mechanism to convey such > data to the PSAP. The mechanism uses a Uniform Resource Identifier > (URI), which may point to either an external resource or an object in > the body of the SIP message. The mechanism thus allows the data to > be passed by reference (when the URI points to an external resource) > or by value (when it points into the body of the message). This > follows the tradition of prior emergency services standardization > work where data can be conveyed by value within the call signaling > (i.e., in body of the SIP message) and also by reference. Working Group Summary > There was a good amount of work group participation in contributing, > discussing, and revising the details that make up the draft. There > were no significant controversies noted on the list, and all dialogues > were efficiently attended to with during the development stage. A > successful development progression is documented in the ECRIT working > group minutes and in email list archives. Personnel > Document shepherd is Marc Linsner. > Area Director is Alissa Cooper. From nobody Mon Oct 12 22:18:29 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFF551B37A1 for ; Mon, 12 Oct 2015 22:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuURYDaiQKvR for ; Mon, 12 Oct 2015 22:18:21 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 038941B3798 for ; Mon, 12 Oct 2015 22:18:20 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-01.telecomsys.com (8.14.7/8.14.7) with ESMTP id t9D5I4V1003808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Oct 2015 22:18:04 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.231]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0248.002; Mon, 12 Oct 2015 22:18:04 -0700 From: Roger Marshall To: "Rosen, Brian (Brian.Rosen@neustar.biz)" , "hgs@cs.columbia.edu" , "Hannes Tschofenig (Hannes.Tschofenig@arm.com)" Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.txt Thread-Index: AQHQ1CX2WxEvs+PLiUCaEuI5s05ooZ5pQ/bQ Date: Tue, 13 Oct 2015 05:18:03 +0000 Message-ID: References: <20150811110743.23776.62645.idtracker@ietfa.amsl.com> In-Reply-To: <20150811110743.23776.62645.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 05:18:23 -0000 Authors: Does this version -10 resolve any/all WGLC comments raised? -roger. -----Original Message----- From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of internet-drafts@ie= tf.org Sent: Tuesday, August 11, 2015 4:08 AM To: i-d-announce@ietf.org Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Emergency Context Resolution with Interne= t Technologies Working Group of the IETF. Title : Data-Only Emergency Calls Authors : Brian Rosen Henning Schulzrinne Hannes Tschofenig Filename : draft-ietf-ecrit-data-only-ea-10.txt Pages : 22 Date : 2015-08-11 Abstract: RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' describes how devices use the Internet to place emergency calls and how Public Safety Answering Points (PSAPs) can handle Internet multimedia emergency calls natively. The exchange of multimedia traffic typically involves a SIP session establishment starting with a SIP INVITE that negotiates various parameters for that session. In some cases, however, the transmission of application data is everything that is needed. Examples of such environments include a temperature sensors issuing alerts, or vehicles sending crash data. Often these alerts are conveyed as one-shot data transmissions. These type of interactions are called 'data-only emergency calls'. This document describes a container for the data based on the Common Alerting Protocol (CAP) and its transmission using the SIP MESSAGE transaction. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-10 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From nobody Mon Oct 12 23:45:14 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A31091B3961 for ; Mon, 12 Oct 2015 23:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwFBhucaUyyY for ; Mon, 12 Oct 2015 23:45:11 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06E571B395C for ; Mon, 12 Oct 2015 23:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1444718712; x=1476254712; h=message-id:in-reply-to:references:date:to:from:subject: cc:mime-version; bh=C828Bm0QK/Ewsxkoml2bbqwAgJ1uVzCyUC2+kNeiLiI=; b=mDWRvA/daNXFfomQISFcoxg7n5MKBOfD7BjhCMEdAUErSmcupYItbt9D SSmis6NM/Lb4HcI8l8W70UZL1mBiOcUg8UXoWo3pwXu/mXhf5LJvf9+FK sRY0jjYCRDUIVGFkUo4Cehqdco/tT1+4+6UkVPxbEBPzCfhQGzMgighi3 g=; X-IronPort-AV: E=McAfee;i="5700,7163,7952"; a="236458410" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by wolverine02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Oct 2015 23:45:11 -0700 X-IronPort-AV: E=Sophos;i="5.17,676,1437462000"; d="scan'208";a="1067561497" Received: from nasanexm02f.na.qualcomm.com ([10.85.0.87]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 12 Oct 2015 23:45:10 -0700 Received: from [192.168.5.193] (10.80.80.8) by nasanexm02f.na.qualcomm.com (10.85.0.87) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 12 Oct 2015 23:44:59 -0700 Message-ID: In-Reply-To: References: <20150811110743.23776.62645.idtracker@ietfa.amsl.com> X-Mailer: Eudora for Mac OS X Date: Mon, 12 Oct 2015 23:45:00 -0700 To: Roger Marshall , "Rosen, Brian (Brian.Rosen@neustar.biz)" , "hgs@cs.columbia.edu" , "Hannes Tschofenig (Hannes.Tschofenig@arm.com)" From: Randall Gellens MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To nasanexm02f.na.qualcomm.com (10.85.0.87) Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2015 06:45:12 -0000 No. after discussions with Brian at the July IETF, I emailed him an edited version of the XML with all of my suggested changes, but Brian never got arund to doing anything with them, and then Hannes uploaded -10 without benefit of my changes, so now they are out of synch and someone needs to do the work to integrate my changes and Hannes'. At 5:18 AM +0000 10/13/15, Roger Marshall wrote: > Authors: > Does this version -10 resolve any/all WGLC comments raised? > > -roger. > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of > internet-drafts@ietf.org > Sent: Tuesday, August 11, 2015 4:08 AM > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.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 : Data-Only Emergency Calls > Authors : Brian Rosen > Henning Schulzrinne > Hannes Tschofenig > Filename : draft-ietf-ecrit-data-only-ea-10.txt > Pages : 22 > Date : 2015-08-11 > > Abstract: > RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' > describes how devices use the Internet to place emergency calls and > how Public Safety Answering Points (PSAPs) can handle Internet > multimedia emergency calls natively. The exchange of multimedia > traffic typically involves a SIP session establishment starting with > a SIP INVITE that negotiates various parameters for that session. > > In some cases, however, the transmission of application data is > everything that is needed. Examples of such environments include a > temperature sensors issuing alerts, or vehicles sending crash data. > Often these alerts are conveyed as one-shot data transmissions. > These type of interactions are called 'data-only emergency calls'. > This document describes a container for the data based on the Common > Alerting Protocol (CAP) and its transmission using the SIP MESSAGE > transaction. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-data-only-ea-10 > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > CONFIDENTIALITY NOTICE: The information contained in this message > may be privileged and/or confidential. If you are not the intended > recipient, or responsible for delivering this message to the > intended recipient, any review, forwarding, dissemination, > distribution or copying of this communication or any attachment(s) > is strictly prohibited. If you have received this message in error, > please notify the sender immediately, and delete it and all > attachments from your computer and network. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Accident: A condition in which presence of mind is good, but absence of body is better. From nobody Wed Oct 14 14:41:27 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC52C1A8A23 for ; Wed, 14 Oct 2015 14:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j7aafNHsz7X for ; Wed, 14 Oct 2015 14:41:24 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90221A8A1D for ; Wed, 14 Oct 2015 14:41:23 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-01.telecomsys.com (8.14.7/8.14.7) with ESMTP id t9ELf2uA015185 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Oct 2015 14:41:02 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.231]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0248.002; Wed, 14 Oct 2015 14:41:02 -0700 From: Roger Marshall To: Randall Gellens , "Rosen, Brian (Brian.Rosen@neustar.biz)" , "hgs@cs.columbia.edu" , "Hannes Tschofenig (Hannes.Tschofenig@arm.com)" Thread-Topic: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.txt Thread-Index: AQHQ1CX2WxEvs+PLiUCaEuI5s05ooZ5pQ/bQgACOcwCAAhc9sA== Date: Wed, 14 Oct 2015 21:41:00 +0000 Message-ID: References: <20150811110743.23776.62645.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 21:41:26 -0000 Thanks Randy for providing feedback. -roger. -----Original Message----- From: Randall Gellens [mailto:randy@qti.qualcomm.com]=20 Sent: Monday, October 12, 2015 11:45 PM To: Roger Marshall; Rosen, Brian (Brian.Rosen@neustar.biz); hgs@cs.columbia= .edu; Hannes Tschofenig (Hannes.Tschofenig@arm.com) Cc: ecrit@ietf.org Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.txt No. after discussions with Brian at the July IETF, I emailed him an edited= version of the XML with all of my suggested changes, but Brian never got a= rund to doing anything with them, and then Hannes uploaded -10 without benefit of my changes, so now they are out of synch and someone= needs to do the work to integrate my changes and Hannes'. At 5:18 AM +0000 10/13/15, Roger Marshall wrote: > Authors: > Does this version -10 resolve any/all WGLC comments raised? > > -roger. > > -----Original Message----- > From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of=20 > internet-drafts@ietf.org > Sent: Tuesday, August 11, 2015 4:08 AM > To: i-d-announce@ietf.org > Cc: ecrit@ietf.org > Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > This draft is a work item of the Emergency Context Resolution with=20 > Internet Technologies Working Group of the IETF. > > Title : Data-Only Emergency Calls > Authors : Brian Rosen > Henning Schulzrinne > Hannes Tschofenig > Filename : draft-ietf-ecrit-data-only-ea-10.txt > Pages : 22 > Date : 2015-08-11 > > Abstract: > RFC 6443 'Framework for Emergency Calling Using Internet Multimedia' > describes how devices use the Internet to place emergency calls and > how Public Safety Answering Points (PSAPs) can handle Internet > multimedia emergency calls natively. The exchange of multimedia > traffic typically involves a SIP session establishment starting with > a SIP INVITE that negotiates various parameters for that session. > > In some cases, however, the transmission of application data is > everything that is needed. Examples of such environments include a > temperature sensors issuing alerts, or vehicles sending crash data. > Often these alerts are conveyed as one-shot data transmissions. > These type of interactions are called 'data-only emergency calls'. > This document describes a container for the data based on the Common > Alerting Protocol (CAP) and its transmission using the SIP MESSAGE > transaction. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-10 > > > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at=20 > tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > CONFIDENTIALITY NOTICE: The information contained in this message may=20 > be privileged and/or confidential. If you are not the intended=20 > recipient, or responsible for delivering this message to the intended=20 > recipient, any review, forwarding, dissemination, distribution or=20 > copying of this communication or any attachment(s) is strictly=20 > prohibited. If you have received this message in error, please notify=20 > the sender immediately, and delete it and all attachments from your=20 > computer and network. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- Accident: A condition in which presence of mind is good, but absence of bod= y is better. From nobody Wed Oct 14 14:45:01 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BA01A8A47 for ; Wed, 14 Oct 2015 14:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p3wiDJQVaeA4 for ; Wed, 14 Oct 2015 14:44:58 -0700 (PDT) Received: from sea-mx-01.telecomsys.com (sea-mx-01.telecomsys.com [199.165.246.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27AE1A8A45 for ; Wed, 14 Oct 2015 14:44:58 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-01.telecomsys.com (8.14.7/8.14.7) with ESMTP id t9ELiuv4005572 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 14 Oct 2015 14:44:56 -0700 Received: from SEA-EXMB-1.telecomsys.com ([169.254.1.231]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0248.002; Wed, 14 Oct 2015 14:44:56 -0700 From: Roger Marshall To: "'ECRIT'" Thread-Topic: Request for Agenda Items - IETF94 Thread-Index: AdEGyY6gvv43n/cnTJObsODgKJRr2A== Date: Wed, 14 Oct 2015 21:44:55 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Rosen, Brian \(Brian.Rosen@neustar.biz\)" , "Alissa Cooper \(alcoop\) \(alcoop@cisco.com\)" Subject: [Ecrit] Request for Agenda Items - IETF94 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Oct 2015 21:44:59 -0000 WG: Please let us know if you want to present your ECRIT related draft(s) at IE= TF94 in Yokohama. Roger Marshall & Marc Linsner - ECRIT chairs CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. From nobody Thu Oct 15 01:25:35 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056421A9071 for ; Thu, 15 Oct 2015 01:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJmos38pK_GN for ; Thu, 15 Oct 2015 01:25:31 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDCEF1A906C for ; Thu, 15 Oct 2015 01:25:31 -0700 (PDT) Received: by pabws5 with SMTP id ws5so17231622pab.3 for ; Thu, 15 Oct 2015 01:25:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=VeALouME/aSV+/E4DsSSxmSmWHzLN4af+nYx6JH6qMc=; b=dQt8dulrQrM6VafpcUm9R9D8MnlrPCSkXDCc0lpnd5yK5eflcKUlXo7IxnmjmJTmFI S6kFSfTaHY91IjQxAuX3febQ8msdOVwNzpCmlfwBiCGN8Zw6AXSCLub6kKiJSfCA2YkX 1YpuPvmcWrfxzy2QWei9rCszw+NAsEtyk2DoSujp+OjFw9FWnuXCDYyLB/mEOSEj5LSV 74olKmB7SSZ2JXd5lRyAY8X79SWuSAaCz+Cd4IFcTcwvbQyQ4BIg+M1bCOMg1SiNXkJ6 Z28NdMizLAdFfHvfpL4iVCKev2CazunuOv7jDkGVc3lpcf3kpjVpSUagmbVtGQxT6itT H6wA== X-Received: by 10.66.121.137 with SMTP id lk9mr8697007pab.87.1444897531408; Thu, 15 Oct 2015 01:25:31 -0700 (PDT) Received: from [192.168.1.100] ([1.144.74.190]) by smtp.gmail.com with ESMTPSA id fb1sm13934533pab.9.2015.10.15.01.25.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 Oct 2015 01:25:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Thu, 15 Oct 2015 19:25:27 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2B2ED92C-FF9E-428B-989F-C4F08F87AE04@gmail.com> <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> To: Roger Marshall X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 08:25:34 -0000 Hey Roger, Any movement on this? Cheers James > On 26 Sep 2015, at 5:18 am, Roger Marshall = wrote: >=20 > James: > Yes. We will submit an IESG request for this draft soon. >=20 > -roger. >=20 > -----Original Message----- > From: James Winterbottom [mailto:a.james.winterbottom@gmail.com]=20 > Sent: Sunday, September 13, 2015 11:14 PM > To: Roger Marshall > Cc: ecrit_ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing >=20 > Hi Roger et al, >=20 > It has now been nearly two weeks since you sent this to the list and = the update was published during the last IETF meeting. > This seems like plenty of time for Keith to have replied with further = comments. Can we please forward with this document? >=20 > Cheers > James >=20 >=20 >> On 1 Sep 2015, at 9:18 am, Roger Marshall = wrote: >>=20 >> Keith, do the changes that James offered satisfy your issues? =20 >>=20 >> -roger. >>=20 >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of James = Winterbottom >> Sent: Sunday, August 09, 2015 2:00 AM >> To: ecrit_ietf.org >> Subject: [Ecrit] draft-ietf-ecrit-held-routing >>=20 >> Hi All, >>=20 >> The only comments received during the WGLC were from Keith Drage and = I believe that I addressed all of these in a rev of the draft but I = haven=E2=80=99t heard anything back. >>=20 >> Keith, can you please confirm that your issues have all been = addressed by the new text and if they have then can we please move the = draft forward? >>=20 >> Cheers >> James >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. >=20 From nobody Thu Oct 15 09:07:37 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC33D1AC3E9 for ; Thu, 15 Oct 2015 09:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw50FEKRK5G2 for ; Thu, 15 Oct 2015 09:07:28 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F8861A6F49 for ; Thu, 15 Oct 2015 09:07:28 -0700 (PDT) Received: from [192.168.131.140] ([80.92.122.113]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MDn8s-1ZnLPd3rQs-00H61T; Thu, 15 Oct 2015 18:07:12 +0200 To: Randall Gellens , Roger Marshall , "Rosen, Brian (Brian.Rosen@neustar.biz)" , "hgs@cs.columbia.edu" , "Hannes Tschofenig (Hannes.Tschofenig@arm.com)" References: <20150811110743.23776.62645.idtracker@ietfa.amsl.com> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <561FCEF3.10101@gmx.net> Date: Thu, 15 Oct 2015 18:06:11 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aSOJkkLNoOS3IBleXruAWdOAGjq6KCiVn" X-Provags-ID: V03:K0:Cj5PwGrPQF6igEy6E1sUoVF9NPDWu6jomkhuNhNjOoWoUVanZR6 SPARoQJ+EBkeeLY2aNjwTYc6WsBi6aZ3brtO5DFvVGIT5uMbfiFn7cr3vJMAB7zkUY+E09M DhzynOra2Abcp0tMbn2yklFngt0Cvg3qgww8p0XZ8ngJl8hFQ/taWAz/oFZq9BIKYHle5MX VK42FGlFElBhcL60WBc+Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:OOJShpoNlAE=:KJHm7AcAQSVeY3F6bUGzRd E9O7Y89UUiJrsylk0wEeSu8KfyN8LroFI8EBMi1itoItAdJKtBP1XGGHE+hxZI05y+EAlB/rg FuvOWAgAMGj5Ak2ZA9Bab5ZpXjmE6PFRoKi91WCXgk/qnYNxIOGLEQ1MefaE+2V/A0aEconVP foejQNBD5slENVrG/KRM+FiSjeSHnDjxPS/dI0mfgccZJYc/aq8N34eLhFDpm0RLCru3u6cM2 l0s351K8porbckO/o/xoLKmdvjwdFTPhlon6Z2DUpsM/exj29aGEhfMOpJklFjkpW9zniM0j/ 8KCUSeOIH4nJPt8xGxL5K+yky1fxr9KTNvMasSOI4m4wykHN/JQk9U04QOw13K2X5F0H9MjSZ s9ABHECRbdjcSH5f1jHlO3iGSUWv4bwhWeblRkAJHJwR//xciy3YeN1hi2ZHowwdsXTGJgrw7 TrOOtdFBE/jMSxe/PsHEQNY/iSvGMxh8w0tT6mZg+eYeUj+xYaeLExKuUTFQzNFesTWN3ByhL cfyoVsWp8BlwmcwUQpqrup8q8pHO7NeS2glpHyJZV2N7ShCMrEQxRKYNmR97jxpX1zN/gbwRb Ofuhyjmcr0CbcClYaHwv5Lvn8pkArCsC92LqabndwDudxFTN93kNCJ58H6EAXjUkqJcKZ6VvX l8UtfrqoyRk7j5pDyppnlGyxu3c3MQEm6DMGJdN1pb2uDO3l1wdgTHDon18eVIrze4pbBCR+8 c4QN5NSP4KY1WNgZ9WS3iPN9X1sZCDE6FodhQD0rkhtR9BP8QdGV1Bxy0BU= Archived-At: Cc: "ecrit@ietf.org" Subject: Re: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2015 16:07:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aSOJkkLNoOS3IBleXruAWdOAGjq6KCiVn Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Can you mail the changes you have proposed around so that I can incorporate them? Ciao Hannes On 10/13/2015 08:45 AM, Randall Gellens wrote: > No. after discussions with Brian at the July IETF, I emailed him an > edited version of the XML with all of my suggested changes, but Brian > never got arund to doing anything with them, and then Hannes uploaded > -10 without benefit of my changes, so now they are out of synch and > someone needs to do the work to integrate my changes and Hannes'. >=20 > At 5:18 AM +0000 10/13/15, Roger Marshall wrote: >=20 >> Authors: >> Does this version -10 resolve any/all WGLC comments raised? >> >> -roger. >> >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of >> internet-drafts@ietf.org >> Sent: Tuesday, August 11, 2015 4:08 AM >> To: i-d-announce@ietf.org >> Cc: ecrit@ietf.org >> Subject: [Ecrit] I-D Action: draft-ietf-ecrit-data-only-ea-10.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 : Data-Only Emergency Calls >> Authors : Brian Rosen >> Henning Schulzrinne >> Hannes Tschofenig >> Filename : draft-ietf-ecrit-data-only-ea-10.txt >> Pages : 22 >> Date : 2015-08-11 >> >> Abstract: >> RFC 6443 'Framework for Emergency Calling Using Internet Multimedi= a' >> describes how devices use the Internet to place emergency calls an= d >> how Public Safety Answering Points (PSAPs) can handle Internet >> multimedia emergency calls natively. The exchange of multimedia >> traffic typically involves a SIP session establishment starting wi= th >> a SIP INVITE that negotiates various parameters for that session. >> >> In some cases, however, the transmission of application data is >> everything that is needed. Examples of such environments include = a >> temperature sensors issuing alerts, or vehicles sending crash data= =2E >> Often these alerts are conveyed as one-shot data transmissions. >> These type of interactions are called 'data-only emergency calls'.= >> This document describes a container for the data based on the Comm= on >> Alerting Protocol (CAP) and its transmission using the SIP MESSAGE= >> transaction. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-ecrit-data-only-ea/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-ecrit-data-only-ea-10 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ecrit-data-only-ea-10 >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >> >> CONFIDENTIALITY NOTICE: The information contained in this message may= >> be privileged and/or confidential. If you are not the intended >> recipient, or responsible for delivering this message to the intended >> recipient, any review, forwarding, dissemination, distribution or >> copying of this communication or any attachment(s) is strictly >> prohibited. If you have received this message in error, please notify >> the sender immediately, and delete it and all attachments from your >> computer and network. >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 --aSOJkkLNoOS3IBleXruAWdOAGjq6KCiVn Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJWH870AAoJEGhJURNOOiAtk9gH/3qjPKapIJ6ElnsCZ0H6wAHu U1JmbTkopcMF6be4vc2hBObqB6xiF2Jtd6nYhBD5zWqHIxFhrUzZ48wjclW2qSlg bzr+ZqwNr3WZWMtvV/kGF8YmlQiA6vqHoA529vUgRkZGdls1TFu1IIh4HSbiqrQA oxjpN0idBmKuQy94lnvv768vHDYHic5yk20Wx2/wOPEfxWS1C25Nm9wEsGIEF6zO iAfCjMNoRXkTVGPy93FDwzvCuJy5SNsz2C+uMgAzYa460/slTGS0txjH5EgmHCp8 Hot5ExP91tK3QuNKwYDAb/1YUk/6WBWeIfX/kcUOYJL0RIxe0s6qDN0Gz9QS14g= =chNh -----END PGP SIGNATURE----- --aSOJkkLNoOS3IBleXruAWdOAGjq6KCiVn-- From nobody Sun Oct 18 13:59:21 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B84F51AD0AB; Sun, 18 Oct 2015 13:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRxR-91zZGag; Sun, 18 Oct 2015 13:59:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 686FF1AD0AE; Sun, 18 Oct 2015 13:59:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151018205918.31246.96781.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 13:59:18 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-ecall-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 20:59:19 -0000 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 : Next-Generation Pan-European eCall Authors : Randall Gellens Hannes Tschofenig Filename : draft-ietf-ecrit-ecall-04.txt Pages : 43 Date : 2015-10-18 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of the Pan European in- vehicle emergency call service defined under the eSafety initiative of the European Commission (generally referred to as "eCall"). eCall is a standardized and mandated system for a special form of emergency calls placed by vehicles. eCall deployment is required in the very near future in European Union member states, and eCall (and eCall- compatible systems) are also being deployed in other regions. eCall provides an integrated voice path and a standardized set of vehicle, sensor (e.g., crash related), and location data. An eCall is recognized and handled as a specialized form of emergency call and is routed to a specialized eCall-capable Public Safety Answering Point (PSAP) capable of processing the vehicle data and trained in handling emergency calls from vehicles. Currently, eCall functions over circuit-switched cellular telephony; work on next-generation eCall (NG-eCall, sometimes called packet- switched eCall or PS-eCall) is now in process, and this document assists in that work by describing how to support eCall within the IP-based emergency services infrastructure. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the eCall vehicle data. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-ecall-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-ecall-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Oct 18 13:59:31 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659441AD0AE; Sun, 18 Oct 2015 13:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPuKYoHNuAMB; Sun, 18 Oct 2015 13:59:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 085691AD0B0; Sun, 18 Oct 2015 13:59:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151018205925.11035.12508.idtracker@ietfa.amsl.com> Date: Sun, 18 Oct 2015 13:59:25 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-car-crash-04.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2015 20:59:28 -0000 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 : Next-Generation Vehicle-Initiated Emergency Calls Authors : Randall Gellens Brian Rosen Hannes Tschofenig Filename : draft-ietf-ecrit-car-crash-04.txt Pages : 26 Date : 2015-10-18 Abstract: This document describes how to use IP-based emergency services mechanisms to support the next generation of emergency calls placed by vehicles (automatically in the event of a crash or serious incident, or manually invoked by a vehicle occupant) and conveying vehicle, sensor, and location data related to the crash or incident. Such calls are often referred to as "Automatic Crash Notification" (ACN), or "Advanced Automatic Crash Notification" (AACN), even in the case of manual trigger. The "Advanced" qualifier refers to the ability to carry a richer set of data. This document also registers a MIME Content Type and an Emergency Call Additional Data Block for the vehicle, sensor, and location data (often referred to as "crash data" even though there is not necessarily a crash). An external specification for the data format, contents, and structure are referenced in this document. This document reuses the technical aspects of next-generation pan- European eCall (a mandated and standardized system for emergency calls by in-vehicle systems within Europe and other regions). However, this document specifies a different set of vehicle (crash) data, specifically, the Vehicle Emergency Data Set (VEDS) rather than the eCall Minimum Set of Data (MSD). This document is an extension of the eCall document, with the differences being that this document makes the MSD data set optional and VEDS mandatory. This document also discusses legacy (curcuit-switched) ACN systems and their migration to next-generation emergency calling. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-car-crash-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-car-crash-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 05:21:22 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 880861A0381 for ; Mon, 19 Oct 2015 05:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZt_Ndy5xBpJ for ; Mon, 19 Oct 2015 05:21:19 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CAC1A0370 for ; Mon, 19 Oct 2015 05:21:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=239; q=dns/txt; s=iport; t=1445257279; x=1446466879; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=v5qkuC7S39Z1pWfqILuJnWCNYL+nE3dIUfYnIF2cWRM=; b=lpcubd/Hf3VtuQcOyaozR/KJmiIAQBTDHKAISYlVGt6OH+QggghKrN9u Mij+6rwvKhMqzoEi2ikHLlb1o4igyWoYQks+zqFcdeSUo+X6S3m+OZOnQ HZoCudVR3qLuGWvN53akoPb/ADoA8uuS64TH6WXo17JRPFteHJGyXvEAe k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AxAgAR3yRW/4wNJK1egzZUG1UFuWeEIQENgVohhXSBQTgUAQEBAQEBAX8LhDQdHVEBPkInBIhDDaA/okkBAQEBBgEBAQEBAR2Gd4IQhykBAYNxgRQFliMBhRiIBIFYSIN0hzOBFo06AR8BAUKEA4UZOoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="199438366" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP; 19 Oct 2015 12:21:18 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t9JCLIAM019970 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Oct 2015 12:21:18 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 07:21:00 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 07:21:00 -0500 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: WGLC - Next-Generation Vehicle-Initiated Emergency Calls Thread-Index: AQHRCmidP2oeaMXMlkKR9ouuR+U4vw== Date: Mon, 19 Oct 2015 12:21:00 +0000 Message-ID: <5A3E20FE-89A2-4AE6-BC1C-5F6D2DD464DB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.148.100] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ecrit] WGLC - Next-Generation Vehicle-Initiated Emergency Calls X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 12:21:20 -0000 Today starts a working group last call for: http://datatracker.ietf.org/doc/draft-ietf-ecrit-car-crash/ Please review the document and send comments to the ECRIT mail list by CoB = on October 30, 2015. Thanks, Marc & Roger From nobody Mon Oct 19 05:23:23 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52D41A0363 for ; Mon, 19 Oct 2015 05:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcifSKITn5c0 for ; Mon, 19 Oct 2015 05:23:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D2731A026C for ; Mon, 19 Oct 2015 05:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=236; q=dns/txt; s=iport; t=1445257400; x=1446467000; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=7SyJQ/ZiTt30TNe0cJneh7SPEulzVZVdcBmWGx6RXSI=; b=YUHmiwBl1hGnQAWQNYUvn0VXsVwHqWwLNJvNeunb2wfAWH4kXzvGeu2g VUoJxDJRWJGQTLrd2rmS25XaU3zilqjhWXY5kCInEt7znf9UIYEDjdkkw yhGpUimvzyUuGQMG04OdBBZJuzDOxVAyiDiP8vDhWBP4V+27ww7cyR3t9 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CmBQCH4CRW/4wNJK1egzZUG1UFuWeGCSGFdIFBOxEBAQEBAQEBfwuENB0dUQE+QicEiEMNoEKiSQEBAQEGAQEBAQEBHYZ3ghCHKQEBg3GBFAWWIwGFGIgEgVhIg3SHM4EWjToBNyyEA4UZOoEGAQEB X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="38817219" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP; 19 Oct 2015 12:23:10 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t9JCNAAQ021421 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 19 Oct 2015 12:23:10 GMT Received: from xch-aln-010.cisco.com (173.36.7.20) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 07:22:51 -0500 Received: from xch-aln-010.cisco.com ([173.36.7.20]) by XCH-ALN-010.cisco.com ([173.36.7.20]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 07:22:51 -0500 From: "Marc Linsner (mlinsner)" To: "ecrit@ietf.org" Thread-Topic: WGLC - Next-Generation Pan-European eCall Thread-Index: AQHRCmjfkoOcnetYPUmiJe0ZJyXtgw== Date: Mon, 19 Oct 2015 12:22:51 +0000 Message-ID: <2428E20A-65E4-400F-BB3B-53B0764A1B88@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.148.100] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Ecrit] WGLC - Next-Generation Pan-European eCall X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 12:23:21 -0000 Today starts a working group last call for: http://datatracker.ietf.org/doc/draft-ietf-ecrit-ecall/ Please review the document and send comments to the ECRIT mail list by CoB = on October 30, 2015. Thanks, Marc & Roger= From nobody Mon Oct 19 12:23:17 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C52171B2C64 for ; Mon, 19 Oct 2015 12:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GTc2p4wq-TIN for ; Mon, 19 Oct 2015 12:22:54 -0700 (PDT) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D55A1B2C67 for ; Mon, 19 Oct 2015 12:22:53 -0700 (PDT) Received: by lbcao8 with SMTP id ao8so152844727lbc.3 for ; Mon, 19 Oct 2015 12:22:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=TTmsgsqq8pNimnKwKHc4TZ3JycvXa/ITP3lmg1X6Cxk=; b=my7E4WEKCPe5XgILB5VEcHlPQ+PaJ/QQJcPFXkEOL1vu2LLh+AhymGh6G2+GTRmUhG OeCC0ctpbh9ZWrJlgBWjb9vQ8dRVPK6fy4DjHgk/nY/YetS8qMjIiuZ3nSrVhlRHynt0 3/F8FcHDQY16bUSx/uENYEd/jhLCd6kszp0CCyMQ5gotW30KQN1KNfmzA8rTw183UfH+ smSk3v9mRujTDXFPZLriwCPxfhO4F06vZZhtdnrAHZu4R2z9sF2hxUP6R8jouKYFti1U RkVSsFEr48xQnAjI2834TMK1WpV/gTLr++EKH8+gbeAOVqBjSepcKeiAK+cEAII1/Mxb yI7A== X-Gm-Message-State: ALoCoQnbX7i9UKXJik8YearHPrW+jDjfwSJiP9idJzY639a6N3r2WtxyuKBVaGT1QXzqAFqIKH5l MIME-Version: 1.0 X-Received: by 10.112.155.195 with SMTP id vy3mr15865537lbb.9.1445282571665; Mon, 19 Oct 2015 12:22:51 -0700 (PDT) Received: by 10.25.212.80 with HTTP; Mon, 19 Oct 2015 12:22:51 -0700 (PDT) X-Originating-IP: [209.173.53.233] In-Reply-To: <20151019192057.13904.36636.idtracker@ietfa.amsl.com> References: <20151019192057.13904.36636.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 15:22:51 -0400 Message-ID: From: Brian Rosen To: "ecrit@ietf.org" Content-Type: multipart/alternative; boundary=089e0115ff2a48e20e05227a128a Archived-At: Subject: [Ecrit] Fwd: I-D Action: draft-rosen-ecrit-lost-planned-changes-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 19:22:56 -0000 --089e0115ff2a48e20e05227a128a Content-Type: text/plain; charset=UTF-8 I have made a number of small edits to improve readibility of this document. Could a few of you review this critically? I will be asking for work group adoption in Yokohama. Brian ---------- Forwarded message ---------- From: Date: Mon, Oct 19, 2015 at 3:20 PM Subject: I-D Action: draft-rosen-ecrit-lost-planned-changes-03.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Validation of Locations Around a Planned Change Author : Brian Rosen Filename : draft-rosen-ecrit-lost-planned-changes-03.txt Pages : 10 Date : 2015-10-19 Abstract: This document defines an extension to LoST (RFC5222) that allows a planned change to the data in the LoST server to occur. Records that previously were valid will become invalid at a date in the future, and new locations will become valid after the date. The extension adds two elements to the request: a URI to be used to inform the LIS that previously valid locations will be invalid after the planned change date, and add a date which requests the server to perform validation as of the date specified. It also adds an optional TTL element to the response, which informs all queriers the current expected lifetime of the validation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-rosen-ecrit-lost-planned-changes/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-rosen-ecrit-lost-planned-changes-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-rosen-ecrit-lost-planned-changes-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --089e0115ff2a48e20e05227a128a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have made a number of small edits to improve readibility= of this document.=C2=A0 Could a few of you review this critically?=C2=A0 I= will be asking for work group adoption in Yokohama.

Bri= an


---------- Forward= ed message ----------
From: <internet-drafts@ie= tf.org>
Date: Mon, Oct 19, 2015 at 3:20 PM
Subject: I-D= Action: draft-rosen-ecrit-lost-planned-changes-03.txt
To: i-d-announce@ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Validation of Locations Around a Planned Change
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Author=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Bria= n Rosen
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ros= en-ecrit-lost-planned-changes-03.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 10
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-10-19

Abstract:
=C2=A0 =C2=A0This document defines an extension to LoST (RFC5222) that allo= ws a
=C2=A0 =C2=A0planned change to the data in the LoST server to occur.=C2=A0 = Records that
=C2=A0 =C2=A0previously were valid will become invalid at a date in the fut= ure,
=C2=A0 =C2=A0and new locations will become valid after the date.=C2=A0 The = extension
=C2=A0 =C2=A0adds two elements to the <findservice> request: a URI to= be used to
=C2=A0 =C2=A0inform the LIS that previously valid locations will be invalid= after
=C2=A0 =C2=A0the planned change date, and add a date which requests the ser= ver to
=C2=A0 =C2=A0perform validation as of the date specified.=C2=A0 It also add= s an
=C2=A0 =C2=A0optional TTL element to the response, which informs all querie= rs the
=C2=A0 =C2=A0current expected lifetime of the validation.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org= /doc/draft-rosen-ecrit-lost-planned-changes/

There's also a htmlized version available at:
https://tools.ietf.org/html/dra= ft-rosen-ecrit-lost-planned-changes-03

A diff from the previous version is available at:
https://www.ietf.org/rf= cdiff?url2=3Ddraft-rosen-ecrit-lost-planned-changes-03


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/m= ailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--089e0115ff2a48e20e05227a128a-- From nobody Mon Oct 19 13:48:14 2015 Return-Path: X-Original-To: ecrit@ietf.org Delivered-To: ecrit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E9B81ACD74; Mon, 19 Oct 2015 13:47:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.6.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20151019204754.1242.58682.idtracker@ietfa.amsl.com> Date: Mon, 19 Oct 2015 13:47:54 -0700 Archived-At: Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action: draft-ietf-ecrit-similar-location-01.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2015 20:47:54 -0000 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 : A LoST extension to return complete and similar location info Authors : Roger Marshall Jeff Martin Brian Rosen Filename : draft-ietf-ecrit-similar-location-01.txt Pages : 16 Date : 2015-10-19 Abstract: This document introduces a new way to provide returned location information in LoST responses that is either of a completed or similar form to the original input civic location, based on whether valid or invalid civic address elements are returned within the findServiceResponse message. This document defines a new extension to the findServiceResponse message within the LoST protocol [RFC5222] that enables the LoST protocol to return a completed civic address element set for a valid location response, and one or more suggested sets of similar location information for invalid LoST responses. These two types of civic addresses are referred to as either "complete location" or "similar location", and are included as compilation of ca type xml elements within the existing LoST findServiceResponse message structure. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ecrit-similar-location/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ecrit-similar-location-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ecrit-similar-location-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 26 10:50:46 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96DB01B2FD6 for ; Mon, 26 Oct 2015 10:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkXfif1Nh02r for ; Mon, 26 Oct 2015 10:50:34 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97D751B2FF8 for ; Mon, 26 Oct 2015 10:50:34 -0700 (PDT) Received: by pabla5 with SMTP id la5so1563506pab.0 for ; Mon, 26 Oct 2015 10:50:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=O7Jal8zCy8okhvk34w+UEmTTINqarqq/OKJyDUrzrnw=; b=0k7PzqFJkJp92gO0P9OJnQgFIjR+rt0dAKuMqs6h1ABoZ4BmfgZByacVxRuUTMxe1x W34f2YBlB/su5l0ijt9i7RVC7mXp9/CcKRQkONroE7q24l1IsSlbY+dYJ4LhoYH4iRyb 3eV6CNSMGRfHvDRbSDQd/mD9SHrGosabKXYiiVKyJHO/uHl83WC22qOLDsPaoU1hdeys PrfRWvfaI/uJelOiCeRWbfOfqjGIBQ9IaEGq3LPNy8R+yaJBiLPf5vJlsFjLV7maL1rG MotAlFaJdY4hrpRTBqjq/Q4+QCCkFrM31MPTVe0sekHWzRugP7UGZCd0yv+ukN4MvYmX +q4w== X-Received: by 10.68.165.35 with SMTP id yv3mr23401925pbb.53.1445881834211; Mon, 26 Oct 2015 10:50:34 -0700 (PDT) Received: from [192.168.1.11] (124-170-212-174.dyn.iinet.net.au. [124.170.212.174]) by smtp.gmail.com with ESMTPSA id pn8sm35108395pbb.16.2015.10.26.10.50.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Oct 2015 10:50:33 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Tue, 27 Oct 2015 04:50:29 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <6C7659F8-CD39-4571-8946-4B5C17F313A2@gmail.com> References: <2B2ED92C-FF9E-428B-989F-C4F08F87AE04@gmail.com> <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> To: Roger Marshall X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 17:50:43 -0000 Hi Roger, Can you please provide an update on this? Cheers James > On 26 Sep 2015, at 5:18 am, Roger Marshall = wrote: >=20 > James: > Yes. We will submit an IESG request for this draft soon. >=20 > -roger. >=20 > -----Original Message----- > From: James Winterbottom [mailto:a.james.winterbottom@gmail.com]=20 > Sent: Sunday, September 13, 2015 11:14 PM > To: Roger Marshall > Cc: ecrit_ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing >=20 > Hi Roger et al, >=20 > It has now been nearly two weeks since you sent this to the list and = the update was published during the last IETF meeting. > This seems like plenty of time for Keith to have replied with further = comments. Can we please forward with this document? >=20 > Cheers > James >=20 >=20 >> On 1 Sep 2015, at 9:18 am, Roger Marshall = wrote: >>=20 >> Keith, do the changes that James offered satisfy your issues? =20 >>=20 >> -roger. >>=20 >> -----Original Message----- >> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of James = Winterbottom >> Sent: Sunday, August 09, 2015 2:00 AM >> To: ecrit_ietf.org >> Subject: [Ecrit] draft-ietf-ecrit-held-routing >>=20 >> Hi All, >>=20 >> The only comments received during the WGLC were from Keith Drage and = I believe that I addressed all of these in a rev of the draft but I = haven=E2=80=99t heard anything back. >>=20 >> Keith, can you please confirm that your issues have all been = addressed by the new text and if they have then can we please move the = draft forward? >>=20 >> Cheers >> James >>=20 >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www.ietf.org/mailman/listinfo/ecrit >>=20 >> CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. >=20 From nobody Mon Oct 26 10:55:07 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DC761A1AB9 for ; Mon, 26 Oct 2015 10:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMnbsGySWq8U for ; Mon, 26 Oct 2015 10:55:03 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA831B2F94 for ; Mon, 26 Oct 2015 10:55:03 -0700 (PDT) Received: from SEA-EXCAS-1.telecomsys.com (exc2010-local1.telecomsys.com [10.32.12.186]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id t9QHsxgL000836 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Mon, 26 Oct 2015 10:54:59 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.227]) by SEA-EXCAS-1.telecomsys.com ([10.32.12.186]) with mapi id 14.03.0248.002; Mon, 26 Oct 2015 10:54:58 -0700 From: Roger Marshall To: James Winterbottom Thread-Topic: [Ecrit] draft-ietf-ecrit-held-routing Thread-Index: AQHQ0oHdzIsQK6ZQJUCOLHhQGQsfRZ4m4OtAgBVYaoCAEa9DcIAxFVeA//+LtPA= Date: Mon, 26 Oct 2015 17:54:58 +0000 Message-ID: References: <2B2ED92C-FF9E-428B-989F-C4F08F87AE04@gmail.com> <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> <6C7659F8-CD39-4571-8946-4B5C17F313A2@gmail.com> In-Reply-To: <6C7659F8-CD39-4571-8946-4B5C17F313A2@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 17:55:06 -0000 SGkgSmFtZXM6DQpJIHBsYW4gdG8gcmVxdWVzdCB0aGlzIHN1Ym1pc3Npb24gYnkgRU9EIHRvbW9y cm93Lg0KDQotcm9nZXIuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBKYW1l cyBXaW50ZXJib3R0b20gW21haWx0bzphLmphbWVzLndpbnRlcmJvdHRvbUBnbWFpbC5jb21dIA0K U2VudDogTW9uZGF5LCBPY3RvYmVyIDI2LCAyMDE1IDEwOjUwIEFNDQpUbzogUm9nZXIgTWFyc2hh bGwNCkNjOiBlY3JpdF9pZXRmLm9yZw0KU3ViamVjdDogUmU6IFtFY3JpdF0gZHJhZnQtaWV0Zi1l Y3JpdC1oZWxkLXJvdXRpbmcNCg0KSGkgUm9nZXIsDQoNCkNhbiB5b3UgcGxlYXNlIHByb3ZpZGUg YW4gdXBkYXRlIG9uIHRoaXM/DQoNCkNoZWVycw0KSmFtZXMNCg0KDQo+IE9uIDI2IFNlcCAyMDE1 LCBhdCA1OjE4IGFtLCBSb2dlciBNYXJzaGFsbCA8Uk1hcnNoYWxsQHRlbGVjb21zeXMuY29tPiB3 cm90ZToNCj4gDQo+IEphbWVzOg0KPiBZZXMuICBXZSB3aWxsIHN1Ym1pdCBhbiBJRVNHIHJlcXVl c3QgZm9yIHRoaXMgZHJhZnQgc29vbi4NCj4gDQo+IC1yb2dlci4NCj4gDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEphbWVzIFdpbnRlcmJvdHRvbSBbbWFpbHRvOmEuamFt ZXMud2ludGVyYm90dG9tQGdtYWlsLmNvbV0gDQo+IFNlbnQ6IFN1bmRheSwgU2VwdGVtYmVyIDEz LCAyMDE1IDExOjE0IFBNDQo+IFRvOiBSb2dlciBNYXJzaGFsbA0KPiBDYzogZWNyaXRfaWV0Zi5v cmcNCj4gU3ViamVjdDogUmU6IFtFY3JpdF0gZHJhZnQtaWV0Zi1lY3JpdC1oZWxkLXJvdXRpbmcN Cj4gDQo+IEhpIFJvZ2VyIGV0IGFsLA0KPiANCj4gSXQgaGFzIG5vdyBiZWVuIG5lYXJseSB0d28g d2Vla3Mgc2luY2UgeW91IHNlbnQgdGhpcyB0byB0aGUgbGlzdCBhbmQgdGhlIHVwZGF0ZSB3YXMg cHVibGlzaGVkIGR1cmluZyB0aGUgbGFzdCBJRVRGIG1lZXRpbmcuDQo+IFRoaXMgc2VlbXMgbGlr ZSBwbGVudHkgb2YgdGltZSBmb3IgS2VpdGggdG8gaGF2ZSByZXBsaWVkIHdpdGggZnVydGhlciBj b21tZW50cy4gQ2FuIHdlIHBsZWFzZSBmb3J3YXJkIHdpdGggdGhpcyBkb2N1bWVudD8NCj4gDQo+ IENoZWVycw0KPiBKYW1lcw0KPiANCj4gDQo+PiBPbiAxIFNlcCAyMDE1LCBhdCA5OjE4IGFtLCBS b2dlciBNYXJzaGFsbCA8Uk1hcnNoYWxsQHRlbGVjb21zeXMuY29tPiB3cm90ZToNCj4+IA0KPj4g S2VpdGgsIGRvIHRoZSBjaGFuZ2VzIHRoYXQgSmFtZXMgb2ZmZXJlZCBzYXRpc2Z5IHlvdXIgaXNz dWVzPyAgDQo+PiANCj4+IC1yb2dlci4NCj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4+IEZyb206IEVjcml0IFttYWlsdG86ZWNyaXQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEphbWVzIFdpbnRlcmJvdHRvbQ0KPj4gU2VudDogU3VuZGF5LCBBdWd1c3QgMDksIDIw MTUgMjowMCBBTQ0KPj4gVG86IGVjcml0X2lldGYub3JnDQo+PiBTdWJqZWN0OiBbRWNyaXRdIGRy YWZ0LWlldGYtZWNyaXQtaGVsZC1yb3V0aW5nDQo+PiANCj4+IEhpIEFsbCwNCj4+IA0KPj4gVGhl IG9ubHkgY29tbWVudHMgcmVjZWl2ZWQgZHVyaW5nIHRoZSBXR0xDIHdlcmUgZnJvbSBLZWl0aCBE cmFnZSBhbmQgSSBiZWxpZXZlIHRoYXQgSSBhZGRyZXNzZWQgYWxsIG9mIHRoZXNlIGluIGEgcmV2 IG9mIHRoZSBkcmFmdCBidXQgSSBoYXZlbuKAmXQgaGVhcmQgYW55dGhpbmcgYmFjay4NCj4+IA0K Pj4gS2VpdGgsIGNhbiB5b3UgcGxlYXNlIGNvbmZpcm0gdGhhdCB5b3VyIGlzc3VlcyBoYXZlIGFs bCBiZWVuIGFkZHJlc3NlZCBieSB0aGUgbmV3IHRleHQgYW5kIGlmIHRoZXkgaGF2ZSB0aGVuIGNh biB3ZSBwbGVhc2UgbW92ZSB0aGUgZHJhZnQgZm9yd2FyZD8NCj4+IA0KPj4gQ2hlZXJzDQo+PiBK YW1lcw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+PiBFY3JpdEBpZXRmLm9yZw0KPj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9lY3JpdA0KPj4gDQo+PiBDT05GSURFTlRJ QUxJVFkgTk9USUNFOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBt YXkgYmUgcHJpdmlsZWdlZCBhbmQvb3IgY29uZmlkZW50aWFsLiBJZiB5b3UgYXJlIG5vdCB0aGUg aW50ZW5kZWQgcmVjaXBpZW50LCBvciByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGlzIG1l c3NhZ2UgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgYW55IHJldmlldywgZm9yd2FyZGluZywg ZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBjb21tdW5pY2F0 aW9uIG9yIGFueSBhdHRhY2htZW50KHMpIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGltbWVkaWF0ZWx5LCBhbmQgZGVsZXRlIGl0IGFuZCBhbGwgYXR0YWNobWVudHMgZnJvbSB5 b3VyIGNvbXB1dGVyIGFuZCBuZXR3b3JrLg0KPiANCg0K From nobody Mon Oct 26 10:56:18 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4391C1B4A52 for ; Mon, 26 Oct 2015 10:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDnZSlA1keAC for ; Mon, 26 Oct 2015 10:56:15 -0700 (PDT) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812261B47ED for ; Mon, 26 Oct 2015 10:56:15 -0700 (PDT) Received: by pacfv9 with SMTP id fv9so203520010pac.3 for ; Mon, 26 Oct 2015 10:56:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=7Rh+3u8iN0S9REbJU6KH6EltL9j/eK19PnHZIkWZHCc=; b=yJ0DVa738Byz5Z0aJF/mkIQqxoV4itunfyf4d9ROVTXH379F31nFv9MRXPXdIf24JS d8HVSQvOSHY8Ji9e/pKhUews9uOHedzO1lPi1B7mYRCsJQxucrzSQwUGzExmzbGr5lvm jBEoaINYlGubNr9zwc8GJQotehgwRxWP5p+YzQCW7nT/6uC6AW25xOymPY69IG8ekJMc SnxkgumUHFCjejuuw/uSZh+hRN6wO5zo4FG7vD8GSSmUqNWG4oIEQW+JdDsSAK0sTOFk CNFENqGVRJwXCD9CiCQvjAeMjaJi7q1pPYJQEXY3as3wcbE40XkA+cuK91gRVPVjgMzF xivw== X-Received: by 10.67.2.34 with SMTP id bl2mr11259433pad.63.1445882175097; Mon, 26 Oct 2015 10:56:15 -0700 (PDT) Received: from [192.168.1.11] (124-170-212-174.dyn.iinet.net.au. [124.170.212.174]) by smtp.gmail.com with ESMTPSA id y5sm35084600pbt.77.2015.10.26.10.56.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 26 Oct 2015 10:56:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: James Winterbottom In-Reply-To: Date: Tue, 27 Oct 2015 04:56:10 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <509C53CA-C4B0-4B21-A6D4-7C813FCDC4CF@gmail.com> References: <2B2ED92C-FF9E-428B-989F-C4F08F87AE04@gmail.com> <4B8D7CA3-D92A-4044-94A4-3DAF4E4A2E47@gmail.com> <6C7659F8-CD39-4571-8946-4B5C17F313A2@gmail.com> To: Roger Marshall X-Mailer: Apple Mail (2.2104) Archived-At: Cc: "ecrit_ietf.org" Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2015 17:56:17 -0000 Thanks Roger. > On 27 Oct 2015, at 4:54 am, Roger Marshall = wrote: >=20 > Hi James: > I plan to request this submission by EOD tomorrow. >=20 > -roger. >=20 > -----Original Message----- > From: James Winterbottom [mailto:a.james.winterbottom@gmail.com]=20 > Sent: Monday, October 26, 2015 10:50 AM > To: Roger Marshall > Cc: ecrit_ietf.org > Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing >=20 > Hi Roger, >=20 > Can you please provide an update on this? >=20 > Cheers > James >=20 >=20 >> On 26 Sep 2015, at 5:18 am, Roger Marshall = wrote: >>=20 >> James: >> Yes. We will submit an IESG request for this draft soon. >>=20 >> -roger. >>=20 >> -----Original Message----- >> From: James Winterbottom [mailto:a.james.winterbottom@gmail.com]=20 >> Sent: Sunday, September 13, 2015 11:14 PM >> To: Roger Marshall >> Cc: ecrit_ietf.org >> Subject: Re: [Ecrit] draft-ietf-ecrit-held-routing >>=20 >> Hi Roger et al, >>=20 >> It has now been nearly two weeks since you sent this to the list and = the update was published during the last IETF meeting. >> This seems like plenty of time for Keith to have replied with further = comments. Can we please forward with this document? >>=20 >> Cheers >> James >>=20 >>=20 >>> On 1 Sep 2015, at 9:18 am, Roger Marshall = wrote: >>>=20 >>> Keith, do the changes that James offered satisfy your issues? =20 >>>=20 >>> -roger. >>>=20 >>> -----Original Message----- >>> From: Ecrit [mailto:ecrit-bounces@ietf.org] On Behalf Of James = Winterbottom >>> Sent: Sunday, August 09, 2015 2:00 AM >>> To: ecrit_ietf.org >>> Subject: [Ecrit] draft-ietf-ecrit-held-routing >>>=20 >>> Hi All, >>>=20 >>> The only comments received during the WGLC were from Keith Drage and = I believe that I addressed all of these in a rev of the draft but I = haven=E2=80=99t heard anything back. >>>=20 >>> Keith, can you please confirm that your issues have all been = addressed by the new text and if they have then can we please move the = draft forward? >>>=20 >>> Cheers >>> James >>>=20 >>> _______________________________________________ >>> Ecrit mailing list >>> Ecrit@ietf.org >>> https://www.ietf.org/mailman/listinfo/ecrit >>>=20 >>> CONFIDENTIALITY NOTICE: The information contained in this message = may be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. >>=20 >=20 From nobody Wed Oct 28 14:43:32 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1D891B5EB7; Wed, 28 Oct 2015 14:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Po5eH2GuRIyq; Wed, 28 Oct 2015 14:43:25 -0700 (PDT) Received: from sea-mx-02.telecomsys.com (sea-mx-02.telecomsys.com [199.165.246.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B22B1B5EB6; Wed, 28 Oct 2015 14:43:25 -0700 (PDT) Received: from SEA-EXCAS-3.telecomsys.com (exc2010-local3.telecomsys.com [10.32.12.6]) by sea-mx-02.telecomsys.com (8.14.7/8.14.7) with ESMTP id t9SLhKvv017726 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Wed, 28 Oct 2015 14:43:21 -0700 Received: from SEA-EXMB-2.telecomsys.com ([169.254.2.227]) by SEA-EXCAS-3.telecomsys.com ([10.32.12.6]) with mapi id 14.03.0248.002; Wed, 28 Oct 2015 14:43:20 -0700 From: Roger Marshall To: "iesg-secretary@ietf.org" Thread-Topic: Request to Publish draft-ietf-ecrit-held-routing-03 Thread-Index: AdERyahWvISvBJ3eQ5O+RfVHPe/YyQ== Date: Wed, 28 Oct 2015 21:43:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.12.134] Content-Type: multipart/alternative; boundary="_000_FBD5AAFFD0978846BF6D3FAB4C892ACC28EE04DBSEAEXMB2telecom_" MIME-Version: 1.0 Archived-At: Cc: "ecrit@ietf.org" Subject: [Ecrit] Request to Publish draft-ietf-ecrit-held-routing-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Oct 2015 21:43:32 -0000 --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC28EE04DBSEAEXMB2telecom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The ECRIT working group would like to publish draft-ietf-ecrit-held-routing= -03 The PROTO write-up is below. Roger Marshall ECRIT co-chair Document Shepherd Writeup per RFC 4858 template, (dated 24 February 2012), = for the following work group draft: A Routing Request Extension for the HELD Protocol http://datatracker.ietf.org/doc/ draft-ietf-ecrit-held-routing-03/ (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? RFC type being requested for this draft is "Proposed Standard", since the draft describes normative changes to the HELD protocol for use in emergency services. The title page lists it currently as "Standard". (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. [Abstract] For cases where location servers have access to emergency routing information they are able to return routing information with the location information if the location request includes a request for the desired routing information. This document specifies an extension to the HELD protocol to support this function. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? There was significant work group participation in discussion of the approac= h taken within the draft, since it introduces a different way to use the HE= LD protocol, which originally was designed exclusively to convey location i= nformation. There were some controversies noted on the list, and all dialo= gues were efficiently attended to during the development stage. One final = objection was noted and addressed by the draft author, with no follow up pr= ovided by the commenter, despite ample opportunity/time to do so. A success= ful development progression is documented in the ECRIT work group minutes a= nd in email list archives. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? No existing implementations are known to exist. There have been several ve= ndors that have been involved in the development and review of the document. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Document shepherd is Roger Marshall. Area Director is Alissa Cooper. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. Careful review by the document shepherd following WGLC. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. None noted. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why. Each of the authors confirmed that they were not aware of any existing IPR Relating to this draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. None posted. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is work group consensus to move this document forward to RFC status. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. Yes, see (15) below. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no MIB, media, but does seek to register a new URN sub-namespace as 'urn:ietf:params:xml:ns:geopriv:held:ri' and new IANA registered XML namespace. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. (15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. Two downref errors were reported by the Nits process (listed as Normative References pointing to Informational RFCs). One of the Authors, after being contacted on the subject, reiterated his adherence to the Normative classification for each citing, claiming that formal definition of terms within the Informational RFCs are essential to the understanding of the present draft. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. No referenced RFCs will change in status due to publication of this documen= t. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). All IANA registry requirements have been met. (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. None. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. There are no BNF or MIB parts applicable. The XML examples appear to be well formed. CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC28EE04DBSEAEXMB2telecom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The ECR= IT working group would like to publish draft-ietf-ecrit-held-routing-03

&n= bsp;

The PRO= TO write-up is below.

&n= bsp;

&n= bsp;

Roger M= arshall

ECRIT c= o-chair

&n= bsp;

=  

 

 

Document Shepherd Writeup per RFC 4858 template, (dated 24= February 2012), for the following work group draft:

 

A Routing Request Extension for the HELD Protocol<= /o:p>

http://datatr= acker.ietf.org/doc/ draft-= ietf-ecrit-held-routing-03/

 

 

(1) What type of RFC is being requested (BCP, Proposed = Standard,

Internet Standard, Informational, Experimental, or Hist= oric)?  Why

is this the proper type of RFC?  Is this type of R= FC indicated in the

title page header?

 

RFC type being requested for this draft is “Proposed= Standard”, since

the draft describes normative changes to the HELD protocol= for use in

emergency services.  The title page lists it currentl= y as “Standard”.

 

 

(2) The IESG approval announcement includes a Document = Announcement

Write-Up. Please provide such a Document Announcement W= rite-Up. Recent

examples can be found in the "Action" announc= ements for approved

documents. The approval announcement contains the follo= wing sections:

 

Technical Summary

 

  Relevant content can frequently be found in the = abstract

  and/or introduction of the document. If not= , this may be

  an indication that there are deficiencies i= n the abstract

  or introduction.

 

[Abstract]

 

   For cases where location servers have access = to emergency routing

   information they are able to return routing i= nformation with the

   location information if the location request = includes a request for

   the desired routing information.  This d= ocument specifies an

   extension to the HELD protocol to support thi= s function.

 

 

Working Group Summary

 

  Was there anything in WG process that is worth n= oting? For

  example, was there controversy about partic= ular points or

  were there decisions where the consensus wa= s particularly

  rough?

 

There was significant work group participation in discussi= on of the approach taken within the draft, since it introduces a different = way to use the HELD protocol, which originally was designed exclusively to convey location information.  There were = some controversies noted on the list, and all dialogues were efficiently at= tended to during the development stage.  One final objection was noted= and addressed by the draft author, with no follow up provided by the commenter, despite ample opportunity/time to do = so. A successful development progression is documented in the ECRIT work gr= oup minutes and in email list archives.

 

 

Document Quality

 

  Are there existing implementations of the protoc= ol? Have a

  significant number of vendors indicated the= ir plan to

  implement the specification? Are there any = reviewers that

  merit special mention as having done a thor= ough review,

  e.g., one that resulted in important change= s or a

  conclusion that the document had no substan= tive issues? If

  there was a MIB Doctor, Media Type or other= expert review,

  what was its course (briefly)? In the case = of a Media Type

  review, on what date was the request posted= ?

 

No existing implementations are known to exist.  Ther= e have been several vendors that have been involved in the development and = review of the document.

 

 

Personnel

 

  Who is the Document Shepherd? Who is the Respons= ible Area

  Director?

 

Document shepherd is Roger Marshall. 

Area Director is Alissa Cooper.

 

 

(3) Briefly describe the review of this document that w= as performed by

the Document Shepherd.  If this version of the doc= ument is not ready

for publication, please explain why the document is bei= ng forwarded to

the IESG.

 

Careful review by the document shepherd following WGLC.

 

 

(4) Does the document Shepherd have any concerns about = the depth or

breadth of the reviews that have been performed? 

 

No.

 

 

(5) Do portions of the document need review from a part= icular or from

broader perspective, e.g., security, operational comple= xity, AAA, DNS,

DHCP, XML, or internationalization? If so, describe the= review that

took place.

 

No.

 

 

(6) Describe any specific concerns or issues that the D= ocument Shepherd

has with this document that the Responsible Area Direct= or and/or the

IESG should be aware of? For example, perhaps he or she= is uncomfortable

with certain parts of the document, or has concerns whe= ther there really

is a need for it. In any event, if the WG has discussed= those issues and

has indicated that it still wishes to advance the docum= ent, detail those

concerns here.

 

None noted.

 

 

(7) Has each author confirmed that any and all appropri= ate IPR

disclosures required for full conformance with the prov= isions of BCP 78

and BCP 79 have already been filed. If not, explain why= .

 

Each of the authors confirmed that they were= not aware of any existing IPR

Relating to this draft.

 

 

(8) Has an IPR disclosure been filed that references th= is document?

If so, summarize any WG discussion and conclusion regar= ding the IPR

disclosures.

 

None posted.

 

 

(9) How solid is the WG consensus behind this document?= Does it

represent the strong concurrence of a few individuals, = with others

being silent, or does the WG as a whole understand and = agree with it?  

 

There is work group consensus to move this document forwar= d to RFC status.

 

 

(10) Has anyone threatened an appeal or otherwise indic= ated extreme

discontent? If so, please summarize the areas of confli= ct in separate

email messages to the Responsible Area Director. (It sh= ould be in a

separate email because this questionnaire is publicly a= vailable.)

 

No.

 

 

(11) Identify any ID nits the Document Shepherd has fou= nd in this

document. (See http://www.ietf.org/tools/id= nits/ and the Internet-Drafts

Checklist). Boilerplate checks are not enough; this che= ck needs to be

thorough.

 

Yes, see (15) below.

 

 

(12) Describe how the document meets any required forma= l review

criteria, such as the MIB Doctor, media type, and URI t= ype reviews.

 

There are no MIB, media, but does seek to register a new U= RN sub-namespace

as 'urn:ietf:params:xml:ns:geopriv:held:ri' and new IANA r= egistered XML

namespace.

 

 

(13) Have all references within this document been iden= tified as

either normative or informative?<= /p>

 

Yes.

 

 

(14) Are there normative references to documents that a= re not ready for

advancement or are otherwise in an unclear state? If su= ch normative

references exist, what is the plan for their completion= ?

 

No.

 

 

(15) Are there downward normative references (see RFC 3= 967)?

If so, list these downward references to support the Ar= ea Director in

the Last Call procedure.

 

Two downref errors were reported by the Nits process (list= ed as Normative

References pointing to Informational RFCs).  One of t= he Authors, after

being contacted on the subject, reiterated his adherence t= o the Normative

classification for each citing, claiming that formal defin= ition of terms

within the Informational RFCs are essential to the underst= anding of the

present draft.

 

 

(16) Will publication of this document change the statu= s of any

existing RFCs? Are those RFCs listed on the title page = header, listed

in the abstract, and discussed in the introduction? If = the RFCs are not

listed in the Abstract and Introduction, explain why, a= nd point to the

part of the document where the relationship of this doc= ument to the

other RFCs is discussed. If this information is not in = the document,

explain why the WG considers it unnecessary.=

 

No referenced RFCs will change in status due to publicatio= n of this document.

 

 

(17) Describe the Document Shepherd's review of the IAN= A considerations

section, especially with regard to its consistency with= the body of the

document. Confirm that all protocol extensions that the= document makes

are associated with the appropriate reservations in IAN= A registries.

Confirm that any referenced IANA registries have been c= learly

identified. Confirm that newly created IANA registries = include a

detailed specification of the initial contents for the = registry, that

allocations procedures for future registrations are def= ined, and a

reasonable name for the new registry has been suggested= (see RFC 5226).

 

All IANA registry requirements have been met.

 

 

(18) List any new IANA registries that require Expert R= eview for future

allocations. Provide any public guidance that the IESG = would find

useful in selecting the IANA Experts for these new regi= stries.

 

None.

 

 

(19) Describe reviews and automated checks performed by= the Document

Shepherd to validate sections of the document written i= n a formal

language, such as XML code, BNF rules, MIB definitions,= etc.

 

There are no BNF or MIB parts applicable. The XML examples= appear to

be well formed.

 

 

<= meta content=3D"TX_HTML32 11.0.211.501" name=3DGENERATOR>

CONFIDENTIALITY NOTICE: The information contained= in this message may be privileged and/or confidential. If you are not the = intended recipient, or responsible for delivering this message to the inten= ded recipient, any review, forwarding, dissemination, distribution or copyi= ng of this communication or any attachment(s) is strictly prohibited. If yo= u have received this message in error, please notify the sender immediately= , and delete it and all attachments from your computer and network.<= /p>=0A --_000_FBD5AAFFD0978846BF6D3FAB4C892ACC28EE04DBSEAEXMB2telecom_-- From nobody Thu Oct 29 05:39:25 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E1D1A00E3; Thu, 29 Oct 2015 05:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PIzev0bomH6; Thu, 29 Oct 2015 05:39:20 -0700 (PDT) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E491A0020; Thu, 29 Oct 2015 05:39:19 -0700 (PDT) Received: by qgem9 with SMTP id m9so32507318qge.1; Thu, 29 Oct 2015 05:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ln8pWxTYwOfy82cbJVWAGwJQW+TFAq8/sri89n8NvsY=; b=HZlNcrNSEEZ6qOLCS2xM1tQ4zwX5qW4xVG+eWTunh//QV3k66TsBR8ZwAsQiQYemij cxmVuLJu8ou3yhZ3t3kAi35R+TZe/YqHWm7BA1qtLwcZCeCoX9eerMmAcmkwdUuUqI8F zWvnUV5SWEpoHsMTh6k2X1Nu3njuJBkyVAtIbv5JJh2Vp/biEbUtl8DUWVx3z4k7PHtj 6DLioJZtcuf/ucToacHSl73QHTLQcOIw6GqnDh06jzjsPslY/JypKIwUgfUnoFk3siRD lM1r9VGf3kkQcgF3kBjnnCxn+kmMkluxVbzRTv8qUhY1+lO5Bqe/p5eRRDSXni7wlD2C hWzw== MIME-Version: 1.0 X-Received: by 10.140.38.149 with SMTP id t21mr1838102qgt.5.1446122358751; Thu, 29 Oct 2015 05:39:18 -0700 (PDT) Received: by 10.55.7.3 with HTTP; Thu, 29 Oct 2015 05:39:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 29 Oct 2015 13:39:18 +0100 Message-ID: From: Laura Liess To: Roger Marshall Content-Type: multipart/alternative; boundary=001a11c117d07ec70d05233d99f6 Archived-At: Cc: "iesg-secretary@ietf.org" , "ecrit@ietf.org" Subject: Re: [Ecrit] Request to Publish draft-ietf-ecrit-held-routing-03 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2015 12:39:24 -0000 --001a11c117d07ec70d05233d99f6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you, Roger, for doing all this work. Laura 2015-10-28 22:43 GMT+01:00 Roger Marshall : > The ECRIT working group would like to publish > draft-ietf-ecrit-held-routing-03 > > > > The PROTO write-up is below. > > > > > > Roger Marshall > > ECRIT co-chair > > > > > > > > > > Document Shepherd Writeup per RFC 4858 template, (dated 24 February 2012)= , > for the following work group draft: > > > > *A Routing Request Extension for the HELD Protocol* > > http://datatracker.ietf.org/doc/ draft-ietf-ecrit-held-routing-03/ > > > > > > *(1) What type of RFC is being requested (BCP, Proposed Standard,* > > *Internet Standard, Informational, Experimental, or Historic)? Why* > > *is this the proper type of RFC? Is this type of RFC indicated in the* > > *title page header?* > > > > RFC type being requested for this draft is =E2=80=9CProposed Standard=E2= =80=9D, since > > the draft describes normative changes to the HELD protocol for use in > > emergency services. The title page lists it currently as =E2=80=9CStanda= rd=E2=80=9D. > > > > > > *(2) The IESG approval announcement includes a Document Announcement* > > *Write-Up. Please provide such a Document Announcement Write-Up. Recent* > > *examples can be found in the "Action" announcements for approved* > > *documents. The approval announcement contains the following sections:* > > > > *Technical Summary* > > > > * Relevant content can frequently be found in the abstract * > > * and/or introduction of the document. If not, this may be * > > * an indication that there are deficiencies in the abstract * > > * or introduction.* > > > > [Abstract] > > > > For cases where location servers have access to emergency routing > > information they are able to return routing information with the > > location information if the location request includes a request for > > the desired routing information. This document specifies an > > extension to the HELD protocol to support this function. > > > > > > *Working Group Summary* > > > > * Was there anything in WG process that is worth noting? For * > > * example, was there controversy about particular points or * > > * were there decisions where the consensus was particularly * > > * rough?* > > > > There was significant work group participation in discussion of the > approach taken within the draft, since it introduces a different way to u= se > the HELD protocol, which originally was designed exclusively to convey > location information. There were some controversies noted on the list, a= nd > all dialogues were efficiently attended to during the development stage. > One final objection was noted and addressed by the draft author, with no > follow up provided by the commenter, despite ample opportunity/time to do > so. A successful development progression is documented in the ECRIT work > group minutes and in email list archives. > > > > > > *Document Quality* > > > > * Are there existing implementations of the protocol? Have a * > > * significant number of vendors indicated their plan to * > > * implement the specification? Are there any reviewers that * > > * merit special mention as having done a thorough review, * > > * e.g., one that resulted in important changes or a * > > * conclusion that the document had no substantive issues? If * > > * there was a MIB Doctor, Media Type or other expert review, * > > * what was its course (briefly)? In the case of a Media Type * > > * review, on what date was the request posted?* > > > > No existing implementations are known to exist. There have been several > vendors that have been involved in the development and review of the > document. > > > > > > *Personnel* > > > > * Who is the Document Shepherd? Who is the Responsible Area* > > * Director?* > > > > Document shepherd is Roger Marshall. > > Area Director is Alissa Cooper. > > > > > > *(3) Briefly describe the review of this document that was performed by* > > *the Document Shepherd. If this version of the document is not ready* > > *for publication, please explain why the document is being forwarded to* > > *the IESG.* > > > > Careful review by the document shepherd following WGLC. > > > > > > *(4) Does the document Shepherd have any concerns about the depth or* > > *breadth of the reviews that have been performed? * > > > > No. > > > > > > *(5) Do portions of the document need review from a particular or from* > > *broader perspective, e.g., security, operational complexity, AAA, DNS,* > > *DHCP, XML, or internationalization? If so, describe the review that* > > *took place.* > > > > No. > > > > > > *(6) Describe any specific concerns or issues that the Document Shepherd* > > *has with this document that the Responsible Area Director and/or the* > > *IESG should be aware of? For example, perhaps he or she is uncomfortable= * > > *with certain parts of the document, or has concerns whether there really= * > > *is a need for it. In any event, if the WG has discussed those issues and= * > > *has indicated that it still wishes to advance the document, detail those= * > > *concerns here.* > > > > None noted. > > > > > > *(7) Has each author confirmed that any and all appropriate IPR* > > *disclosures required for full conformance with the provisions of BCP 78* > > *and BCP 79 have already been filed. If not, explain why.* > > > > Each of the authors confirmed that they were not aware of any existing IP= R > > Relating to this draft. > > > > > > *(8) Has an IPR disclosure been filed that references this document?* > > *If so, summarize any WG discussion and conclusion regarding the IPR* > > *disclosures.* > > > > None posted. > > > > > > *(9) How solid is the WG consensus behind this document? Does it * > > *represent the strong concurrence of a few individuals, with others* > > *being silent, or does the WG as a whole understand and agree with it? = * > > > > There is work group consensus to move this document forward to RFC status= . > > > > > > *(10) Has anyone threatened an appeal or otherwise indicated extreme * > > *discontent? If so, please summarize the areas of conflict in separate* > > *email messages to the Responsible Area Director. (It should be in a* > > *separate email because this questionnaire is publicly available.) * > > > > No. > > > > > > *(11) Identify any ID nits the Document Shepherd has found in this* > > *document. (See http://www.ietf.org/tools/idnits/ > ** and the Internet-Drafts* > > *Checklist). Boilerplate checks are not enough; this check needs to be* > > *thorough.* > > > > Yes, see (15) below. > > > > > > *(12) Describe how the document meets any required formal review* > > *criteria, such as the MIB Doctor, media type, and URI type reviews.* > > > > There are no MIB, media, but does seek to register a new URN sub-namespac= e > > as 'urn:ietf:params:xml:ns:geopriv:held:ri' and new IANA registered XML > > namespace. > > > > > > *(13) Have all references within this document been identified as* > > *either normative or informative?* > > > > Yes. > > > > > > *(14) Are there normative references to documents that are not ready for* > > *advancement or are otherwise in an unclear state? If such normative* > > *references exist, what is the plan for their completion?* > > > > No. > > > > > > *(15) Are there downward normative references (see RFC 3967)?* > > *If so, list these downward references to support the Area Director in * > > *the Last Call procedure. * > > > > Two downref errors were reported by the Nits process (listed as Normative > > References pointing to Informational RFCs). One of the Authors, after > > being contacted on the subject, reiterated his adherence to the Normative > > classification for each citing, claiming that formal definition of terms > > within the Informational RFCs are essential to the understanding of the > > present draft. > > > > > > *(16) Will publication of this document change the status of any* > > *existing RFCs? Are those RFCs listed on the title page header, listed* > > *in the abstract, and discussed in the introduction? If the RFCs are not* > > *listed in the Abstract and Introduction, explain why, and point to the* > > *part of the document where the relationship of this document to the* > > *other RFCs is discussed. If this information is not in the document,* > > *explain why the WG considers it unnecessary.* > > > > No referenced RFCs will change in status due to publication of this > document. > > > > > > *(17) Describe the Document Shepherd's review of the IANA considerations* > > *section, especially with regard to its consistency with the body of the* > > *document. Confirm that all protocol extensions that the document makes* > > *are associated with the appropriate reservations in IANA registries.* > > *Confirm that any referenced IANA registries have been clearly* > > *identified. Confirm that newly created IANA registries include a* > > *detailed specification of the initial contents for the registry, that* > > *allocations procedures for future registrations are defined, and a* > > *reasonable name for the new registry has been suggested (see RFC 5226).* > > > > All IANA registry requirements have been met. > > > > > > *(18) List any new IANA registries that require Expert Review for future* > > *allocations. Provide any public guidance that the IESG would find* > > *useful in selecting the IANA Experts for these new registries.* > > > > None. > > > > > > *(19) Describe reviews and automated checks performed by the Document* > > *Shepherd to validate sections of the document written in a formal* > > *language, such as XML code, BNF rules, MIB definitions, etc.* > > > > There are no BNF or MIB parts applicable. The XML examples appear to > > be well formed. > > > > > > CONFIDENTIALITY NOTICE: The information contained in this message may be > privileged and/or confidential. If you are not the intended recipient, or > responsible for delivering this message to the intended recipient, any > review, forwarding, dissemination, distribution or copying of this > communication or any attachment(s) is strictly prohibited. If you have > received this message in error, please notify the sender immediately, and > delete it and all attachments from your computer and network. > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www.ietf.org/mailman/listinfo/ecrit > > --001a11c117d07ec70d05233d99f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you, Roger, for doing all this work.

Laura

2015-10-28 22:43 GMT+01:00 Roger Marshall <RMarshall@telecomsys.co= m>:

The ECR= IT working group would like to publish draft-ietf-ecrit-held-routing-03<= /u>

= =C2=A0

The PRO= TO write-up is below.

= =C2=A0

= =C2=A0

Roger M= arshall

ECRIT c= o-chair

= =C2=A0

=C2=A0

=C2=A0

=C2=A0

Document Shepherd Writeup per RFC 4858 template, (dated 24= February 2012), for the following work group draft:

=C2=A0

A Routing Request Extension for the HELD Protocol

http://datatracker.ietf.org/doc/ draft-= ietf-ecrit-held-routing-03/

=C2=A0

=C2=A0

(1) What type of RFC is being requested (BCP, Proposed = Standard,

Internet Standard, Informational, Experimental, or Hist= oric)?=C2=A0 Why

is this the proper type of RFC?=C2=A0 Is this type of R= FC indicated in the

title page header?

=C2=A0

RFC type being requested for this draft is =E2=80=9CPropos= ed Standard=E2=80=9D, since

the draft describes normative changes to the HELD protocol= for use in

emergency services.=C2=A0 The title page lists it currentl= y as =E2=80=9CStandard=E2=80=9D.

=C2=A0

=C2=A0

(2) The IESG approval announcement includes a Document = Announcement

Write-Up. Please provide such a Document Announcement W= rite-Up. Recent

examples can be found in the "Action" announc= ements for approved

documents. The approval announcement contains the follo= wing sections:

=C2=A0

Technical Summary

=C2=A0

=C2=A0 Relevant content can frequently be found in the = abstract

=C2=A0=C2=A0and/or introduction of the document. If not= , this may be

=C2=A0=C2=A0an indication that there are deficiencies i= n the abstract

=C2=A0=C2=A0or introduction.

=C2=A0

[Abstract]

=C2=A0

=C2=A0=C2=A0 For cases where location servers have access = to emergency routing

=C2=A0=C2=A0 information they are able to return routing i= nformation with the

=C2=A0=C2=A0 location information if the location request = includes a request for

=C2=A0=C2=A0 the desired routing information.=C2=A0 This d= ocument specifies an

=C2=A0=C2=A0 extension to the HELD protocol to support thi= s function.

=C2=A0

=C2=A0

Working Group Summary

=C2=A0

=C2=A0 Was there anything in WG process that is worth n= oting? For

=C2=A0=C2=A0example, was there controversy about partic= ular points or

=C2=A0=C2=A0were there decisions where the consensus wa= s particularly

=C2=A0=C2=A0rough?

=C2=A0

There was significant work group participation in discussi= on of the approach taken within the draft, since it introduces a different = way to use the HELD protocol, which originally was designed exclusively to convey location information.=C2=A0 There were = some controversies noted on the list, and all dialogues were efficiently at= tended to during the development stage.=C2=A0 One final objection was noted= and addressed by the draft author, with no follow up provided by the commenter, despite ample opportunity/time to do = so. A successful development progression is documented in the ECRIT work gr= oup minutes and in email list archives.

=C2=A0

=C2=A0

Document Quality

=C2=A0

=C2=A0 Are there existing implementations of the protoc= ol? Have a

=C2=A0=C2=A0significant number of vendors indicated the= ir plan to

=C2=A0=C2=A0implement the specification? Are there any = reviewers that

=C2=A0=C2=A0merit special mention as having done a thor= ough review,

=C2=A0=C2=A0e.g., one that resulted in important change= s or a

=C2=A0=C2=A0conclusion that the document had no substan= tive issues? If

=C2=A0=C2=A0there was a MIB Doctor, Media Type or other= expert review,

=C2=A0=C2=A0what was its course (briefly)? In the case = of a Media Type

=C2=A0=C2=A0review, on what date was the request posted= ?

=C2=A0

No existing implementations are known to exist.=C2=A0 Ther= e have been several vendors that have been involved in the development and = review of the document.

=C2=A0

=C2=A0

Personnel

=C2=A0

=C2=A0 Who is the Document Shepherd? Who is the Respons= ible Area

=C2=A0 Director?

=C2=A0

Document shepherd is Roger Marshall.=C2=A0

Area Director is Alissa Cooper.

=C2=A0

=C2=A0

(3) Briefly describe the review of this document that w= as performed by

the Document Shepherd.=C2=A0 If this version of the doc= ument is not ready

for publication, please explain why the document is bei= ng forwarded to

the IESG.

=C2=A0

Careful review by the document shepherd following WGLC.=

=C2=A0

=C2=A0

(4) Does the document Shepherd have any concerns about = the depth or

breadth of the reviews that have been performed?=C2=A0

=C2=A0

No.

=C2=A0

=C2=A0

(5) Do portions of the document need review from a part= icular or from

broader perspective, e.g., security, operational comple= xity, AAA, DNS,

DHCP, XML, or internationalization? If so, describe the= review that

took place.

=C2=A0

No.

=C2=A0

=C2=A0

(6) Describe any specific concerns or issues that the D= ocument Shepherd

has with this document that the Responsible Area Direct= or and/or the

IESG should be aware of? For example, perhaps he or she= is uncomfortable

with certain parts of the document, or has concerns whe= ther there really

is a need for it. In any event, if the WG has discussed= those issues and

has indicated that it still wishes to advance the docum= ent, detail those

concerns here.

=C2=A0

None noted.

=C2=A0

=C2=A0

(7) Has each author confirmed that any and all appropri= ate IPR

disclosures required for full conformance with the prov= isions of BCP 78

and BCP 79 have already been filed. If not, explain why= .

=C2=A0

Each of the authors confirmed that they were= not aware of any existing IPR

Relating to this draft.

=C2=A0

=C2=A0

(8) Has an IPR disclosure been filed that references th= is document?

If so, summarize any WG discussion and conclusion regar= ding the IPR

disclosures.

=C2=A0

None posted.

=C2=A0

=C2=A0

(9) How solid is the WG consensus behind this document?= Does it

represent the strong concurrence of a few individuals, = with others

being silent, or does the WG as a whole understand and = agree with it?=C2=A0=C2=A0

=C2=A0

There is work group consensus to move this document forwar= d to RFC status.

=C2=A0

=C2=A0

(10) Has anyone threatened an appeal or otherwise indic= ated extreme

discontent? If so, please summarize the areas of confli= ct in separate

email messages to the Responsible Area Director. (It sh= ould be in a

separate email because this questionnaire is publicly a= vailable.)

=C2=A0

No.

=C2=A0

=C2=A0

(11) Identify any ID nits the Document Shepherd has fou= nd in this

document. (See http://www= .ietf.org/tools/idnits/ and the Internet-Drafts

Checklist). Boilerplate checks are not enough; this che= ck needs to be

thorough.

=C2=A0

Yes, see (15) below.

=C2=A0

=C2=A0

(12) Describe how the document meets any required forma= l review

criteria, such as the MIB Doctor, media type, and URI t= ype reviews.

=C2=A0

There are no MIB, media, but does seek to register a new U= RN sub-namespace

as 'urn:ietf:params:xml:ns:geopriv:held:ri' and ne= w IANA registered XML

namespace.

=C2=A0

=C2=A0

(13) Have all references within this document been iden= tified as

either normative or informative?

=C2=A0

Yes.

=C2=A0

=C2=A0

(14) Are there normative references to documents that a= re not ready for

advancement or are otherwise in an unclear state? If su= ch normative

references exist, what is the plan for their completion= ?

=C2=A0

No.

=C2=A0

=C2=A0

(15) Are there downward normative references (see RFC 3= 967)?

If so, list these downward references to support the Ar= ea Director in

the Last Call procedure.

=C2=A0

Two downref errors were reported by the Nits process (list= ed as Normative

References pointing to Informational RFCs).=C2=A0 One of t= he Authors, after

being contacted on the subject, reiterated his adherence t= o the Normative

classification for each citing, claiming that formal defin= ition of terms

within the Informational RFCs are essential to the underst= anding of the

present draft.=

=C2=A0

=C2=A0

(16) Will publication of this document change the statu= s of any

existing RFCs? Are those RFCs listed on the title page = header, listed

in the abstract, and discussed in the introduction? If = the RFCs are not

listed in the Abstract and Introduction, explain why, a= nd point to the

part of the document where the relationship of this doc= ument to the

other RFCs is discussed. If this information is not in = the document,

explain why the WG considers it unnecessary.<= /u>

=C2=A0

No referenced RFCs will change in status due to publicatio= n of this document.

=C2=A0

=C2=A0

(17) Describe the Document Shepherd's review of the= IANA considerations

section, especially with regard to its consistency with= the body of the

document. Confirm that all protocol extensions that the= document makes

are associated with the appropriate reservations in IAN= A registries.

Confirm that any referenced IANA registries have been c= learly

identified. Confirm that newly created IANA registries = include a

detailed specification of the initial contents for the = registry, that

allocations procedures for future registrations are def= ined, and a

reasonable name for the new registry has been suggested= (see RFC 5226).

=C2=A0

All IANA registry requirements have been met.

=C2=A0

=C2=A0

(18) List any new IANA registries that require Expert R= eview for future

allocations. Provide any public guidance that the IESG = would find

useful in selecting the IANA Experts for these new regi= stries.

=C2=A0

None.

=C2=A0

=C2=A0

(19) Describe reviews and automated checks performed by= the Document

Shepherd to validate sections of the document written i= n a formal

language, such as XML code, BNF rules, MIB definitions,= etc.

=C2=A0

There are no BNF or MIB parts applicable. The XML examples= appear to

be well formed.

=C2=A0

=C2=A0

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


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


--001a11c117d07ec70d05233d99f6-- From nobody Sat Oct 31 18:10:57 2015 Return-Path: X-Original-To: ecrit@ietfa.amsl.com Delivered-To: ecrit@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 415D31B4B33; Sat, 31 Oct 2015 18:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPi1kL-muKWC; Sat, 31 Oct 2015 18:10:54 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id C4FD01B4B35; Sat, 31 Oct 2015 18:10:54 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E2453180006; Sat, 31 Oct 2015 18:10:05 -0700 (PDT) To: dbanks@ddti.net, hardie@qualcomm.com, andy@hxr.us, hgs+ecrit@cs.columbia.edu, Hannes.Tschofenig@nsn.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20151101011005.E2453180006@rfc-editor.org> Date: Sat, 31 Oct 2015 18:10:05 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, iesg@ietf.org, ecrit@ietf.org Subject: [Ecrit] [Errata Held for Document Update] RFC5222 (4175) X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2015 01:10:56 -0000 The following errata report has been held for document update for RFC5222, "LoST: A Location-to-Service Translation Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5222&eid=4175 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Dan Banks Date Reported: 2014-11-12 Held by: Alissa Cooper (IESG) Section: 12.1 Fig 15 Original Text ------------- 42.656844 -73.348157 Corrected Text -------------- 42.656844 -73.348157 Notes ----- The \\\\'srsName\\\\' in the location provided as part of example in Figure 15 is missing a required \\\\':\\\\' between \\\\'EPSG\\\\' and \\\\'4326\\\\'. -------------------------------------- RFC5222 (draft-ietf-ecrit-lost-10) -------------------------------------- Title : LoST: A Location-to-Service Translation Protocol Publication Date : August 2008 Author(s) : T. Hardie, A. Newton, H. Schulzrinne, H. Tschofenig Category : PROPOSED STANDARD Source : Emergency Context Resolution with Internet Technologies RAI Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG