[Ecrit] (114) Comments on ECRIT Reqs ID

["James M. Polk" <[e-mail]>]

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-requirements-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


Comment #2
Section 2 - Terminology - 2nd paragraph
"protocols" should be singular


Comment #3
Section 2 - Terminology - term
When did IAP become AIP?

IAP and ISP flowed and should be retained.


Comment #4
Section 2 - Terminology - term
basic emergency service - should be capitalized


Comment #5
Section 2 - Terminology - term
"domain" should be renamed "administrative domain"


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...


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


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".


Comment #9
Section 2 - Terminology - term
geographic coordinate system - you fail to mention "a defined meridian", 
which should be added to the definition


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


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")


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"


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?


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?


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).


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.


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...


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."


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".


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?


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.


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.


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


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


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


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.


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.


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.


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"...


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.


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.


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.


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).


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?


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?


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.


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)."


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.


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


Comment #40
    L10.  Preferred datum: The preferred geographic coordinate system for
       emergency calls SHALL be WGS-84.

2D or 3D?


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.


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.


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.


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.


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?


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.


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.


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.


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.


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.


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.


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


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.


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.


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"


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.


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


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

    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.


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.

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ecrit