RE: [Ecrit] (114) Comments on ECRIT Reqs ID
"Roger Marshall" <RMarshall@telecomsys.com> Fri, 01 July 2005 22:39 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoUAJ-0005RC-Gg; Fri, 01 Jul 2005 18:39:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DoUAF-0005R5-Vw for ecrit@megatron.ietf.org; Fri, 01 Jul 2005 18:39:17 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02425 for <ecrit@ietf.org>; Fri, 1 Jul 2005 18:39:12 -0400 (EDT)
Received: from sea-mailsweep-1.telecomsys.com ([206.173.41.176]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DoUaH-00071f-0m for ecrit@ietf.org; Fri, 01 Jul 2005 19:06:11 -0400
Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mailsweep-1.telecomsys.com (Clearswift SMTPRS 5.0.9) with ESMTP id <T71e01a801b0a2000491408@sea-mailsweep-1.telecomsys.com>; Fri, 1 Jul 2005 18:38:57 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Ecrit] (114) Comments on ECRIT Reqs ID
Date: Fri, 01 Jul 2005 15:38:56 -0700
Message-ID: <8C837214C95C864C9F34F3635C2A6575029B5234@SEA-EXCHVS-2.telecomsys.com>
Thread-Topic: [Ecrit] (114) Comments on ECRIT Reqs ID
Thread-Index: AcVZjuhiT+bkGXmHQImpylVqFr6+QAk/dmPw
From: Roger Marshall <RMarshall@telecomsys.com>
To: "James M. Polk" <jmpolk@cisco.com>, ecrit@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 738f70ed28a216241b56e64627db3306
Content-Transfer-Encoding: quoted-printable
Cc:
X-BeenThere: ecrit@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ecrit.ietf.org
List-Unsubscribe: <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
Hello: Below is a follow-up to James' (114!) list of comments to ecrit requirements I-D back on 5/14. We talked about this at the interim meeting, but since there were some straightforward changes that I didn't want to lose, I have gone through individually and made changes to the I-D as noted (grammatical, etc.). For other comments, they're either moot, due to deletes/moves, or have suggestions to push to the ecrit list for resolution, (also noted). My responses in-line within [brackets]. Roger Marshall -----Original Message----- From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf Of James M. Polk Sent: Saturday, May 14, 2005 7:01 PM To: ecrit@ietf.org Subject: [Ecrit] (114) Comments on ECRIT Reqs ID All I reviewed the requirements ID draft-schulzrinne-ecrit-requirements-00.txt for the meeting this coming week, and have a few comments.... ok, 114 comments.... listed.... below.... For those of you attending the interim, I will bring these up there. For those of you not attending the interim, chime in and be heard about this comments. My overall comment to this ID is it is taking on waaaaaay more than the WG charter intended, but I am not surprised. I know a lot of folks want to get specific items addressed here. Some of those items I feel should be addressed elsewhere. Anyway, to the comments - here they are in the order they appear in the doc with one exception, the last one. The last one should be addressed somewhere, and I do not know if it should only be addressed in http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirem ents-02.txt and its next version in the SIP WG. The comments: [note to ID authors - I know this is a group effort, so do not take my use of the word "you" personally] The following is a review of draft-schulzrinne-ecrit-requirements-00 on May 14th, 2005 Comment #1 Section 2 - Terminology - top paragraph "MUSTNOT", "SHALLNOT", "SHOULDNOT" are all 2 words each [RM - Changed in I-D] Comment #2 Section 2 - Terminology - 2nd paragraph "protocols" should be singular [RM - Changed in I-D] Comment #3 Section 2 - Terminology - term When did IAP become AIP? IAP and ISP flowed and should be retained. [interim_mtg_1 Based on a hum, the IAP term won - will through it out to the list /] [RM - take to the list (I haven't seen this resolved)] Comment #4 Section 2 - Terminology - term basic emergency service - should be capitalized [RM - Changed in I-D] Comment #5 Section 2 - Terminology - term "domain" should be renamed "administrative domain" [interim_mtg_2 /] [RM - Changed in I-D and reordered, though this term is not used in the current I-D] Comment #6 Section 2 - Terminology - term You mention "IPSAP" before defining it, and don't state you will define it below like you do other terms. Some call this an IP-PSAP, not an IPSAP, BTW... [RM - Changed all "iPSAP" reference to PSAP as agreed to at interim meeting] Comment #7 Section 2 - Terminology - term emergency caller: The user or user device entity needing sending his/ her location to another entity in the network. "...needing sending..." is poor wording [RM - Change from "needing sending" to "which sends", though this now should be sent to the list based on next comment] Comment #8 Section 2 - Terminology - term emergency caller: The user or user device entity needing sending his/ her location to another entity in the network. The "emergency caller" is "the individual in distress desiring help". [RM - send to the list, since it may better be termed "initiates request for help, rather than "sends location", etc.] Comment #9 Section 2 - Terminology - term geographic coordinate system - you fail to mention "a defined meridian", which should be added to the definition [RM - take to the list (definition as stated taken from www.esri.com/library/glossary/glossary.html which most edu's reference as well)] Comment #10 R2. International: The protocols and protocol extensions developed MUST support regional, political and organizational differences. Motivation: It must be possible for a device or software developed... This "must" in the motivation should be a MUST as it talks normatively [ /] [RM - Changed "must" to "MUST"] Comment #11 R5. Minimum Connectivity: NEED REQUIREMENT HERE Motivation: If there is network connectivity between the emergency caller and the PSAP, and routing information is available, the call should be completed, even if other parts of the network are not reachable. This makes little sense, because if there is connectivity, there is a route, yet the wording seems to believe there might not be (which means there is "no connectivity") [RM - Henning has provided] Comment #12 R6. Incremental Deployment Emergency calls from IP-based devices MUST be incrementally supported. This wording doesn't make sense; should it be: "R6 Incremental Deployment - incremental deployment of IP-based emergency calling MUST be supported" [RM - n/a due to rewritten R6] Comment #13 "R6 Motivation: Any mechanism must be deployable incrementally and work even if not all entities support IP-based emergency calling. For example, User agents conforming to the SIP specification [1], but unaware of this document, must be able to place emergency calls, possibly with restricted functionality." This ID professes that it all about IP e2e connectivity, yet this states it isn't really necessary. Which is it? This motivation, or the wording in the Intro section? [RM - is this now n/a?] Comment #14 R7. Middlebox Reliance: For a transient time the device and the UA MAY use the help of servers (e.g. ESRP) to provide the connectivity to ECC, especially for ECC not yet connected to the Internet. Same as comment to #13 - This ID professes that it all about IP e2e connectivity, yet this states it isn't really necessary. Which is it? This motivation, or the wording in the Intro section? [RM - take to the list] Comment #15 R7 Motivation: Emergency calling mechanisms must support existing emergency call centers based on circuit-switched technology as well as future ECCs that are IP-enabled. This motivation statement clearly contradicts the Intro section (stating this is for IP e2e scenarios). [RM - n/a since R7 removed] Comment #16 A2. Local: Since many countries have already deployed national emergency identifiers, such as 911 in North America and 112 in large parts of Europe, UAs, proxies and call routers MUST recognize these universal emergency identifiers, but MAY NOT recognize lower level local emergency identifiers, including those such as 999, 122, 133, etc. In addition, these same call routing entities SHOULD recognize emergency identifiers that are used in other jurisdictions I don't understand this one as written, as there are ~60 different numbers around the world, we should list which ones are recommended for support and discuss the list. Primary examples are 115, 116, 117 etc for different emergency services within the same jurisdiction. [RM - n/a since A2 removed] Comment #17 A2. Local - [Ed. The requirement A2 is really a set of 3 requirements, and needs to have the question answered which is: "what does the term "local" mean?".] Good question... [RM - n/a] Comment #18 A2 Motivation: The latter requirement is meant to help travelers that may not know the local emergency number and instinctively dial the number they are used to from home. However, it is unlikely that all systems could be programmed to recognize any emergency number used anywhere as some of these numbers are used for non-emergency purposes, in particular extensions and service numbers. What is meant by this last phrase: "... in particular extensions and service numbers." [RM - n/a] Comment #19 A3. Recognizable: Emergency calls MUST be recognizable by user agents, proxies and other network elements. To prevent fraud, an address identified as an emergency number for call features or authentication override MUST also cause routing to a PSAP. Recommend replacing some of the last sentence with: "...any call recognized as an emergency call MUST be delivered expeditiously to an ECC". [RM - A3 needs to be rewritten (need a volunteer)] Comment #20 A5. Secure configuration: Devices SHOULD be assured of the correctness of the local emergency numbers that are automatically configured. How do you "assure a device" without asserting something that requires a key the remote and local domains understand, as well as the UA understands? [RM - n/a since A5 removed] Comment #21 A6. Backwards-compatible: Existing devices that predate the specification of emergency call-related protocols and conventions MUST be able reach a PSAP. I've read this above somewhere else in the ID. If a PIDF-LO is required to complete a 911 call, and it isn't present, and the device doesn't support the error messages from draft-ietf-sipping-location-requirements-02.txt, how can this work? I think this can work in residential and SMB scenarios, but I'm not sure about any others. VPNs in those other network types is but one reason for these problems. [RM - to the list] Comment #22 A7. Common Identifier: User initiated requests using local initiation methods (e.g. 9-1-1) MUST be supported across non-local domains (e.g. foreign countries). This is stated too US-centric. The IETF isn't about a country. This should state that all/most recognizable local emergency numbers will be converted to (perhaps) one SIP user-part for all SIP intermediaries to know to process accordingly. [RM - n/a since A7 removed] Comment #23 A7 Motivation: While traveling, users must be able to use their familiar "home" emergency identifier. Users should also be able to dial the local emergency number in the country they are visiting. Looking at the range of potential numbers, this will be interesting to meet - including just dialing '0' and meaning an emergency call [RM - n/a since A7 removed] Comment #24 Section 5 Proxy-inserted: A proxy along the call path inserts the location or location reference. This violates 3261 and draft-ietf-sipping-location-requirements-02.txt [RM - to the list] Comment #25 L1. Multiple location services: For UA-referenced locations, PSAPs MUST be able to access different location providers. The location provider may be tied to the ASP, AIP or ISP or may be independent of these entities. This may be inside an enterprise, and that should not be underscored or overlooked due to the trust-boundary issues known there [RM - n/a since L1 was removed] Comment #26 L1 Motivation: This requirement avoids that all users have to rely on a single location service provider. This requirement is hard to avoid if there are no traditional national application-layer service providers. I don't understand the first sentence as written, especially since this ID just got done talking about internationalization scope. [RM - n/a since L1 was removed] Comment #27 L2. Civic and Geographic: Where available, both civic (street address) and geographic (longitude/latitude) information SHOULD be provided to the PSAP. This necessitates a PIDF-LO extension to indicate if one was derived from the other. That XML element doesn't exist to my knowledge. [RM - n/a since L2 was removed] Comment #28 L2 Motivation: While geographic coordinate information can usually be translated into civic address location information, "some specific information, such as building number and floor, is more easily provided as civic location information since it does not require a detailed surveying operation". For direct location determination, it may also be easier for the user to check civic location information to assure verity. I don't understand the quoted comment (I put in the quotes BTW) in the first sentence above. Is this suggesting a detailed survey *will* yield the cube number from a GPS coordinate on a non-ground floor? If it won't, it doesn't need to be brought up as motivation. [RM - n/a since L2 was removed] Comment #29 L3. Location source identification: The source of a location data, whether measured, derived (e.g geocoding or reverse geocoding transformation), or manually input, MUST be indicated to the PSAP. How is this not covered by the <method> element in the PIDF-LO, and if so, why is the requirement not just "...the <method> element MUST be present when known"... [RM - n/a since L3 was removed] Comment #30 L3 Motivation: This allows the PSAP to better judge the reliability and accuracy of the data and track down problems. I don't believe the word "judge" is appropriate here, as the PSAPs first need to "learn" (a better word for above) from real world experience what data indicates what results. Down the road, they will then analyze trends and such to determine how best to interpret data. [RM - n/a since L3 was removed] Comment #31 L4. Certifiable: In some cases, the source and generation time of the location object used for call routing and caller location display MUST be verifiable, e.g., by a digital signature. The security requirements describe this in more detail. If my wireline phone has a timestamp of 2002, is that bad/untrusted? I don't believe so. This requirement needs to be adjusted to state this is a function of the <method> the location was derived from. Further, a future document (perhaps years from now) needs to be generated to give recommendations of those functions per <method> value. [RM - n/a since L4 was removed] Comment #32 L5. Multiple locations: Multiple locations MAY be associated with the caller How is this requirement different that L2? If it can be different, then this text needs to state when/how it can be different, yet still be considered good. [RM - n/a since L5 was removed] Comment #33 L5 Motivation: Multiple locations may occur either because the caller has provided more than one civic or geographic (coordinates) location, supplies both civic and geospatial location information, or because different location determination entities make different assessments of the caller's location." There needs to be a requirement stating if there is location information in both formats, and both are depicting the same location (as far as the UA is concerned), they MUST be in the same PIDF-LO; if different - or not sure they are the same location, they need to be in separate PIDF-LOs (typically with different <method> values). [RM - n/a since L5 was removed] Comment #34 L5 Motivation: Multiple locations may occur either because the caller has provided more than one civic or geographic (coordinates) location, supplies both civic and geospatial location information, or because different location determination entities make different assessments of the caller's location." If there are more than one, and they are different, which is trusted to be true? [RM - n/a since L5 was removed] Comment #35 L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. How is "validate" here in L6 different from "certifiable" in L4? [RM - see rewritten L6 (Nadine)] Comment #36 L6. Validation of civic location: It MUST be possible to validate an address prior to its use in an actual emergency call. "... prior to its use in an actual emergency call." should be replaced with: "at any time" only. And...it's an implementation issue when this occurs, so I'm not sure this belongs in the ID. Someone like NENA should be defining this type of requirement. [RM - changed "...validate an address prior to its use in an actual emergency call" to "...validate an Address at any time, including prior to its use in an actual emergency call"] Comment #37 L7. Provide location: Calls using VoIP or subsequent methods MUST supply location with the call. "... with the call" should be replaced with: "...in each Request message (if SIP is used)." [RM - n/a since L7 was removed] Comment #38 L8. Accept two location types: PSAPs shall accept location as civic and/or geo specified. [Ed. Suggest deleting above requirement since it doesn't deal with routing] I disagree with the Ed. Comment because this (as written) limits how many different formats a routing Proxy forwards, and how many formats an ECC has to deal with. The same piece of location information (if in a PIDF-LO) will be used for routing and dispatching. Limiting the number to two here is good. [RM - n/a since L8 was removed] Comment #39 L9. Altitude included with location: All representations of location SHALL include the ability to carry altitude. This requirement does not imply altitude is always used or supplied. Either it does or it doesn't, but "include the ability..." is wishy-washy [RM - n/a see changed L9 text] Comment #40 L10. Preferred datum: The preferred geographic coordinate system for emergency calls SHALL be WGS-84. 2D or 3D? [RM - to the list] Comment #41 L11. Multiple locations: If multiple locations are provided with a call, it SHOULD be possible to identify the most accurate, current, appropriate location information to be used for routing emergency calls and dispatching emergency responders. Exactly how will this be accomplished, especially by a Proxy? This is fruitless, therefore pointless. L2 should be all that is stated for this type of requirement. [RM - n/a since L11 removed] Comment #42 L14. Imprecise location: Imprecise location information MUST be available for emergency call routing and location delivery in cases where precise measurement based location determination mechanisms fail. How is "imprecise location" indicated to the PSAP as "imprecise"? If it cannot be, it shouldn't be a requirement. [RM - n/a since L14 removed] Comment #43 L15. Default identification: PSAPs MUST be made aware when imprecise location information was used to route a call. Same comment here that was to L14 - How is "imprecise location" indicated by the proxy to the PSAP as "imprecise"? If it cannot be, it shouldn't be a requirement. [RM - n/a since L15 removed] Comment #44 L16. Location Responsibility: Location determination MUST assume a responsible party. This is begging for liability statements to be included every time a location is given to a device, that it should not be used unless the user agrees "not to hold the deliverer responsible" before usage. [RM - n/a since L16 removed] Comment #45 L17 Motivation: The location information MUST be attributed to a specific point in time. That is, the location used for routing and which is reported to the PSAP call taker, must be the actual location of the caller at the time of making the call. This makes learning/getting/retrieving location a real-time event as the emergency call is being initiated - and this is not practical. If my home wireline phone has a timestamp of 2002, is that bad? [RM - n/a since L17 removed] Comment #46 L18. Location, Emergency Caller: Location provided with call MUST be associated with an Emergency Caller. Huh? This is to a device, one in which a user might not be logged into. [RM - n/a since L18 removed] Comment #47 L19 Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. The term in the 1st sentence "level" needs to be defined in order to understand if it is met. Level is not currently defined within this ID. [RM - n/a since L19 removed] Comment #48 L19. Location Domain Availability: Location domain MUST be obtainable by Emergency Caller. Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. "Emergency Caller" as used in the 1st sentence - I personally don't care who the authority is, and I doubt most (if any) do outside of this list and some regulators. [RM - n/a since L19 removed] Comment #49 L19. Location Domain Availability: Location domain MUST be obtainable by Emergency Caller. Motivation: Requirement 1 states that a level of authentication and validation for the source of the location is required. This implies the need to for the Emergency Caller to determine the authenticating and validating entity for the emergency services domain in which they reside. That is, it must be possible for an Emergency Caller to discover and utilize an answerable source of location in the access network they are using. This last sentence isn't clear. Provide an example of me discovering an "answerable source" so I can visualize it. [RM - n/a since L19 removed] Comment #50 L20. Location Certification: Location provided MUST be certified. This doesn't account for a GPS chip in a PDA or cell phone, therefore this cannot be a MUST. [RM - n/a since L20 removed] Comment #51 L20 Motivation: The Emergency Caller must be able to establish a session with the access domain authenticating and validating entity to obtain a certified location. The authentication of the location is granted with an expiry time, after which the location within the domain is deemed invalid. "INVALID"? This is starting to look an awful lot like a DHCP lease operation, and we're not building a protocol to do this here. [RM - n/a since L20 removed] Comment #52 L21. Location and Emergency Caller Identity: It MUST NOT be assumed that Emergency Caller identity provided with location is true identity of Emergency Caller. This contradicts L18 [RM - n/a since L21 removed] Comment #53 L22. Location Acceptability: Location provided by Emergency Caller MUST be considered acceptable as input to authentication and validation entity. This isn't really clear. Location should be in a certain format, and there is a 'the' missing in the requirement. [RM - n/a since L22 removed] Comment #54 L22. Location Acceptability: Location provided by Emergency Caller MUST be considered acceptable as input to authentication and validation entity. I see no requirement creating an "authentication and validation entity" which this requirement assumes already exists for every user. [RM - n/a since L22 removed] Comment #55 L24. Location Query Authorization: The ability to query emergency caller location using a location key MUST be limited to authorized end points. "end points" (which is one word BTW) Should be replaced with: "requests" [RM - n/a since L24 removed] Comment #56 L24 Motivation: Where the Emergency Caller does not desire the transmission of their location in-band with their call setup, they shall have the option of requesting a unique query key such that only authorized end points may query the location directly from the domain. As stated above: "end points" (which is one word) Should be replaced with: "requests" As "endpoints" implies the actual device has an SA relationship with the database server, which may not be the case, and only the user created an SA from a log-in screen. This is a two level operation. [RM - n/a since L24 removed] Comment #57 L25. Location Domain Authorization: Location Source entity MUST be authorized within the access domain. This is starting to create an architecture now... and I think this is starting to overstep some bounds of the charter and belongs more in NENA than IETF [RM - n/a since L25 removed] Comment #58 L26. Endpoint Location: Location MUST be tied to an endpoint within the access domain at the time of an emergency call. GPSs violate this, so this cannot be a MUST - see L27 below [RM - n/a since L26 removed] L27. Location Sources: Single source of location MUST NOT be assumed. Motivation: To achieve this, the end user device MUST be able to retrieve its current location from the access provider, from the infrastructure, via GPS, ... or as last resort, from the user itself. [RM - n/a since L27 removed] Comment #59 L28. Location Provided: Endpoint location SHOULD be provided to ECC. This needs to be restated as "if location is provided to the routing proxy, it MUST be provided to the ECC. [RM - see rewritten L28] 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. [RM - take to the list] 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. [RM - see rewritten I4] 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? [RM - n/a since I5 removed] 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? [RM - n/a since I5 removed] 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? [RM - n/a since I6 removed] 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? [RM - see rewritten I7] 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 [RM - see rewritten I10] 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? [RM - n/a since I11 removed] 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 [RM - original I13 deleted, new proposed text by Brian now included in I-D for discussion] 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? [RM - n/a since I15 removed] 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 [RM - n/a since I16 removed] 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 [RM - n/a since I17 removed] 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. [RM - n/a since I18 removed] 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 [RM - n/a since I20 removed] 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. [RM - n/a since I21 removed] 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 [RM - n/a since I22 removed] Comment #79 I23: Any given geographic location SHOULD result in identification of a unique governmentally-authorized PSAP entity for that location? This is repetitive [RM - n/a since I23 removed] 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 [RM - n/a since I24 removed] 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 [RM - see rewritten I25] Comment #82 I26: It MUST be possible for a given PSAP to decide where its calls should be routed. repetitive [RM - n/a since I26 removed] 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. [RM - n/a since I27 removed] 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? [RM - n/a since I28 removed] Comment #85 I32: Multiple types of failures MAY have different contingency routes. Is this a requirement? [RM - n/a since I32 removed] Comment #86 I33: It MUST be possible to provide more than one contingency route for the same type of failure. Duplicate of I31 [RM - n/a since I33 removed] 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 [RM - n/a since I34 removed] Comment #87 I35: Default routes MUST be available when location information is not available. I34 and I35 state the same thing currently [RM - n/a since I35 removed] Comment #88 I36: Entities routing emergency calls SHALL retain information used to choose a route for subsequent error resolution. "... retain information" for how long? [RM - n/a since I36 removed] 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. [RM - n/a since I37 removed] 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 [RM - n/a since I38 removed] 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) [RM - n/a since I39 removed] 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 [RM - see rewritten D1] 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? [RM - n/a since D2 removed] 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." [RM - n/a since D3 removed] 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 [RM - n/a since D4 removed] 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..." [RM - n/a since D6 removed] 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 [RM - see rewritten D7] Comment #99 D8. Multiple query protocols: Directories MAY support multiple query protocols. What does this have to do with routing or identification? [RM - n/a since D8 removed] 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." [RM - D9 to be rewritten, needs an volunteer, why not submit it as above?] 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. [RM - n/a since C1 removed] 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. [RM - n/a since C2 removed] Comment #103 C3. Recontacting Endpoint: The ECC SHOULD have the capability to recontact the initiating endpoint after disconnection. Retitle "Reestablish Communication with Endpoint" [RM - n/a since C3 removed] 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. [RM - n/a since C3 removed] 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..." [RM - n/a since S1 removed] 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)." [RM - n/a since S2 removed] 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? [RM - n/a since S3 removed] 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? [RM - n/a since S6 removed] 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? [RM - n/a since S7 removed] 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. [RM - n/a since S8 removed] 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. [RM - n/a since S9 removed] 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. [RM - suggest bringing up on the list] 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 mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit
- [Ecrit] (114) Comments on ECRIT Reqs ID James M. Polk
- RE: [Ecrit] (114) Comments on ECRIT Reqs ID Roger Marshall