[Ecrit] (114) Comments on ECRIT Reqs ID (part II)
"James M. Polk" <jmpolk@cisco.com> Sun, 15 May 2005 02:10 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX8aG-00010a-0n; Sat, 14 May 2005 22:10:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DX8aD-00010N-TM for ecrit@megatron.ietf.org; Sat, 14 May 2005 22:10:21 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25368 for <ecrit@ietf.org>; Sat, 14 May 2005 22:10:19 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DX8qS-0007kC-P9 for ecrit@ietf.org; Sat, 14 May 2005 22:27:09 -0400
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 14 May 2005 19:10:12 -0700
X-IronPort-AV: i="3.93,109,1115017200"; d="scan'208"; a="265330406:sNHT39309996"
Received: from wells.cisco.com (wells.cisco.com [171.71.177.223]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4F2A7Po011899 for <ecrit@ietf.org>; Sat, 14 May 2005 19:10:07 -0700 (PDT)
Received: from jmpolk-wxp.diablo.cisco.com (sjc-vpn6-455.cisco.com [10.21.121.199]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id TAA22421 for <ecrit@ietf.org>; Sat, 14 May 2005 19:10:06 -0700 (PDT)
Message-Id: <4.3.2.7.2.20050514210355.0206cdb8@diablo.cisco.com>
X-Sender: jmpolk@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Sat, 14 May 2005 21:09:26 -0500
To: ecrit@ietf.org
From: "James M. Polk" <jmpolk@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b271b9c4fc51b08326fa0949e61c0156
Subject: [Ecrit] (114) Comments on ECRIT Reqs ID (part II)
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ecrit@ietf.org>
List-Help: <mailto:ecrit-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ecrit>, <mailto:ecrit-request@ietf.org?subject=subscribe>
Sender: ecrit-bounces@ietf.org
Errors-To: ecrit-bounces@ietf.org
All [*** this is part 2 of a 2 part message to the list - since I received an error posting a message that exceeded 40k, the break between parts is at section 6 of the ID] Comment #60 6. Identifying the Appropriate Emergency Call Center From the previous section, we take the requirement of a single (or small number of) emergency addresses which are independent of the caller's location. However, since for reasons of robustness, jurisdiction and local knowledge, PSAPs only serve a limited geographic region, having the call reach the correct PSAP is crucial. While a PSAP may be able to transfer an errant call, any such transfer is likely to add tens of seconds to call setup latency and is prone to errors. (In the United States, there are about 6,100 PSAPs.) I'd like to see the data justifying this last claim of 10s of seconds statement going forward with IP. Comment #61 6. Identifying the Appropriate Emergency Call Center From the previous section, we take the requirement of a single (or small number of) emergency addresses which are independent of the caller's location. However, since for reasons of robustness, jurisdiction and local knowledge, PSAPs only serve a limited geographic region, having the call reach the correct PSAP is crucial. While a PSAP may be able to transfer an errant call, any such transfer is likely to add tens of seconds to call setup latency and is prone to errors. (In the United States, there are about 6,100 PSAPs.) And only about 600 regions, so this might not be so hard with IP and endpoint provided location Comment #62 Section 6, second paragraph at the end: A UA could conceivably store a complete list of all PSAPs across the world, but that would require frequent synchronization with a master database as PSAPs merge or jurisdictional boundaries change. "change"? This likely isn't so often, BTW Comment #63 Section 6, forth paragraph: Note that the first proxy, the ESRP, doing the translation may not be in the same geographic area as the UA placing the emergency call. "...the first proxy, the ESRP..." Does this assume that any proxy that can route based on the location of the caller is an ESRP? Comment #64 I4. Choice of IPSAPs: The emergency caller SHOULD be provided a choice of emergency call centers if more than one exists and is relevant. This gets into defining what an ECC is (which hasn't been done yet), and that if another number is dialed, it doesn't constitute an emergency call IMO. Comment #65 I5. Assuring IPSAP identity: The emergency caller SHOULD be able to determine conclusively that he has reached an accredited emergency call center. How can this possibly be done? If my display says "Dallas Police Dept." , do I trust it, or do I take the time to verbally question the identity of the calltaker? Do we suggestion questions to be asked to verify the identity of the calltaker? Comment #66 I5 Motivation: This requirement is meant to address the threat that a rogue, possibly criminal, entity pretends to accept emergency calls. How can't this be easily faked? Comment #67 I6. Warnings for unidentifiable IPSAP. Implementations SHOULD allow callers to proceed, with appropriate warnings or user confirmations, if the identity of the destination IPSAP cannot be verified. How is this verified without there being a root key installed in all UAs? Comment #68 I7. Traceable resolution: Particularly for mediated resolution, the caller SHOULD be able to definitively and securely determine who provided the emergency address resolution information. Is this suggesting that all Proxies must remain post transaction/dialog stateful to the user for them to later investigate something? For how long after? Comment #69 I10. Incrementally deployable: An Internet-based emergency call system MUST be able to be deployed incrementally. In the initial stages of deployment, an emergency call may not reach the optimal PSAP. If allowed, emergency calls must only be routed to PSAPs that have agreed to accept non-optimally routed calls. [Ed. Can this be merged with R6?] yes Comment #70 I11. ECC Availability: ECC communication MUST be continuously available. Motivation: From any Internet-connected device it MUST be possible at any time to contact the ECC responsible for the current location with the most appropriate method for communication for the user and the device. is this the famous five 9s? Comment #71 I13. Cross-Jurisdiction Device Support: Devices SHOULD support alternate emergency service systems between countries. Motivation: Even as each country is likely to operate their emergency calling infrastructure differently, SIP devices should be able to reach emergency help and, if possible, be located in any country. [Ed. above text needs clarification] yeah, this doesn't make much sense now Comment #72 I15: It MUST be possible to route a call based on either a civic or a geo location without requiring conversion from one to the other. This requirement does not prohibit an implementation from converting and using the resulting conversion for routing. how is this different from I14? Comment #73 I16: It MUST be possible for a designated 9-1-1 authority to a PSAP to approve of any geocoding database(s) used to assist in determining call routing to that PSAP. Mechanisms must be provided for the PSAP designated 9-1-1 authorities to test and certify a geocoding database as suitable for routing calls to the PSAP. The PSAP may choose to NOT avail itself of such a mechanism. This is implementation - and shouldn't be in here Comment #74 I17: It MUST be possible for the designated 9-1-1 authority to supply, maintain, or approve of databases used for civic routing. Mechanisms must be provided for a designated authority for a PSAP to test and certify a civic routing database as suitable for routing calls to that PSAP. This is implementation - and doesn't belong here Comment #75 I18: It MUST be possible for the PSAP itself (or a contractor it nominates on its behalf) to provide geocode and reverse geocode data and/or conversion services to be used for routing determination. This implies definition of a standard interchange format for geocode data, and protocols to access it. This has nothing to do with Routing the call, and shouldn't be in here. Comment #76 I20: Boundaries for civic routing MUST be able to be specific to a street address range, a side of a street (even/odd street addresses), a building within a "campus", or any of the location fields available. [Ed. Available from where? Please clarify. In the PIDF-LO I think Comment #77 I21: It MUST be possible to use various combined components of the location object for determination of routing. Some areas may only require routing to a country level, others to a state/province, others to a county, or to a municipality, and so on. No assumption should be made on the granularity of routing boundaries or about the combination of components used. The last sentence alone should be the requirement: "No assumption should be made on the granularity of routing boundaries or about the combination of components used." and the text above this sentence removed or used as explanation only. Comment #78 I22: Boundaries mechanisms for geo routing MUST be able to be specific to a natural political boundary, a natural physical boundary (such as a river), or the boundaries listed in the previous requirement. This is repetitive Comment #79 I23: Any given geographic location SHOULD result in identification of a unique governmentally-authorized PSAP entity for that location? This is repetitive Comment #80 I24: Routing databases using 9-1-1 Valid Addresses or lat/lon/ altitude as keys MUST both be available to all entities needing to route 9-1-1 calls. Too US centric Comment #81 I25: Carriers, enterprises and other entities that route emergency calls MUST be able to route calls from any location to its appropriate PSAP. "... to its appropriate PSAP should be replaced with "...towards its appropriate ECC." as the first proxy might no have enough knowledge to do it all Comment #82 I26: It MUST be possible for a given PSAP to decide where its calls should be routed. repetitive Comment #83 I27: It is desirable for higher level civic authorities such as a county or state/province to be able to make common routing decisions for all PSAPs within their jurisdiction. implementation - should be in NENA, not IETF For example, a state may wish to have all emergency calls placed within that state directed to a specific URI. This does NOT imply a single answering point; further routing may occur beyond the common URI. Comment #84 I28: Routing MAY change on short notice due to local conditions, traffic, failures, schedule, etc. this is true with anything IP based, what's the requirement? Comment #85 I32: Multiple types of failures MAY have different contingency routes. Is this a requirement? Comment #86 I33: It MUST be possible to provide more than one contingency route for the same type of failure. Duplicate of I31 Comment #87 I34: A procedure MUST be specified to handle "default route" capability when no location is available or the location information is corrupted. I34 and I35 state the same thing currently Comment #87 I35: Default routes MUST be available when location information is not available. I34 and I35 state the same thing currently Comment #88 I36: Entities routing emergency calls SHALL retain information used to choose a route for subsequent error resolution. "... retain information" for how long? Comment #89 I37: Access Infrastructure providers MUST provide a location object that is as accurate as possible when location measurement or lookup mechanisms fail. "... MUST provide a location object". This is stated incorrectly, the AIP doesn't give the UA its PIDF-LO, it gives it an LCI in most cases. The UA builds/generates the PIDF-LO. Comment #90 I38: Location available at the time that the call is routed MAY not be accurate. Is this a requirement? It's not written as one Comment #91 I39: It SHOULD be possible to have updates of location (which may occur when measuring devices provider early, but imprecise "first fix" location) which can change routing of calls. "... updates of location"... This is a duplicate (L13) Comment #92 7. Emergency Address Directory General comment on this whole section - isn't this sufficiently in the background that this is "architecture" and not "identification" or "routing" in that it doesn't belong in the IETF (but more like NENA)? Comment #93 D1. ECC Identification: Public access to ECC selection information MUST be assumed. Need to mention this is "read only" access Comment #94 D2. Assuring directory identity: The query agent (e.g UA or server) MUST be able to assure that it is querying the intended directory. Without a shared key exchange (ensuring the correct destination is contacted), how can this be accomplished? Comment #95 D3. Query response integrity: The query agent MUST be able to be confident that the query or response has not been tampered with. Suggested rewrite to: "The query agent MUST take appropriate steps to ensure the query or response maintained integrity." Comment #96 D4. Assurance of Update integrity: Any update mechanism for the directory MUST ensure that only authorized users can change directory information and must keep an audit log of all change transactions. This smells like an architectural implementation requirement, therefore it doesn't belong here Comment #97 D6. Multiple directories: A UA or proxy SHOULD be able to use multiple (separate) directories to resolve the emergency identifier. If this can ever be manually entered in a UA or a network server to then be distributed to that network's UAs, then this requirement needs to be opened up to "UA or Proxy or other server SHOULD..." Comment #98 D7. Referral: All directories SHOULD refer out-of-area queries to an appropriate default or region-specific directory. Not sure how this applies to ECRIT Comment #99 D8. Multiple query protocols: Directories MAY support multiple query protocols. What does this have to do with routing or identification? Comment #100 D9. Baseline query protocol: A mandatory-to-implement protocol MUST be specified. Suggested rewording: " A single mandatory-to-implement protocol MUST be specified. Other optional protocols may be listed to give guidance if another protocol is preferred." Comment #101 C1. Identity: The system SHOULD allow (but not force) the identification of both the caller's identity and his or her terminal network address. Doesn't this violate a previous requirement stating the caller's identity cannot be assumed (L21). Plus the definition of "basic emergency service" states this. Comment #102 C2. Privacy override: The end system MUST be able to automatically detect that a call is an emergency call and override any privacy settings that conflict with emergency calling. This doesn't go deep enough into how a jurisdiction may limit how private a caller can remain when calling an ECC. Or the opposite can be true. Comment #103 C3. Recontacting Endpoint: The ECC SHOULD have the capability to recontact the initiating endpoint after disconnection. Retitle "Reestablish Communication with Endpoint" Comment #104 C3 Motivation: Capability to re-contact the contacting device from the ECC in case of disruption or later query for a tbd period of time. This should also be possible from conventional ECC via temporary (virtual) E.164 numbers. All IP means you cannot assume E.164. Comment #105 S1. Authentication override: All outbound proxies and other call filtering elements MUST be able to be configured so that they allow unauthenticated emergency calls. Reword "... MUST be able to be configured..." to "...MUST be configurable..." Comment #106 S2. Mid-call features: The end system MUST be able to recognize an emergency call and allow configuration so that certain call features are not triggered accidentally. Reword " The end system MUST be able to recognize an emergency call and allow configuration so that certain call features are not triggered accidentally." To " The end system MUST recognize it initiated an emergency call and prevent certain call features that interfere with that call (e.g. call waiting, call hold)." Comment #107 In Just after S2 - there needs to be a requirement added stating something to the affect that "...once a UA initiates an emergency call, system resources SHOULD be prevented from certain call features that interfere with that call (e.g. Barge, call preemption). The latter example is for military or government networks. Comment #108 S3. Testable: A user SHOULD be able to test whether a particular address reaches the appropriate PSAP, without actually causing emergency help to be dispatched or consuming PSAP call taker resources. How can't this be faked? Comment #109 S6 Tracking and Tracing Facilities for all calls MUST be provided. This includes all routing entities as well as all signaling entities. "Facilities" reads like circuits and lines. What is meant here? Comment #110 S7 Each element in the signaling and routing paths solution SHALL maintain call detail records that can be accessed by management systems to develop call statistics in real time. Does it really need to be in real-time? Are we talking RTCP statistics? Is this something CALEA would want? How far towards the UAC can a ECC Net Mgmt station gain access to SIP element CDR information? How doesn't this look like a means of attack into an enterprise? Comment #111 S8 Each element of the signaling and routing paths SHALL provide congestion controls. We're talking RSVP and/or MPLS now? Diffserv doesn't do this, and the ECN proposal from Nortel is getting some pushback from Sally Floyd and Fred Baker. Comment #112 S9 It SHALL be possible to determine the complete call chain of a call, including the identity of each signaling element in the path, and the reason it received the call (Call History). We're talking RSVP and/or MPLS now? Diffserv doesn't do this, and the ECN proposal from Nortel is getting some pushback from Sally Floyd and Fred Baker. Comment #113 10. Supplemental Information Owner of the structure or tenant? Where is this in our Charter? SOMETHING TO ADD TO THIS DOCUMENT It is the case in Sweden that when a person calls for emergency help, they MUST provide two different locations in the call set-up. #1 - they MUST provide the location they are calling from (in civic or coordinate format); #2 - they MUST provide their billing location (where they personally receive their bills from. The next version of draft-ietf-sipping-location-requirements-02 (in the SIP WG) will account for this. But I on't know if should only be mentioned there. cheers, James ******************* Truth is not to be argued... it is to be presented. Alas, few *truths* exist without the math. ...all else is a matter of perspective _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit
- [Ecrit] (114) Comments on ECRIT Reqs ID (part II) James M. Polk