Subject: [Ecrit] draft-rosen-nena-ecrit-requirements-00 Review

From: "James M. Polk" <[email-masked]>
Date: Tue, 08 Mar 2005 22:19:56 -0600

Brian/Nadine

In reviewing your ID, I was impressed with the North American 
history/background on 911.

A few comments about the scope and appropriateness of certain requirements 
in the ID:

Req 3.1-1 "Tracking and Tracing Facilities for all calls must be provided."
I don't understand how you're defining "Tracking" and "Tracing" and 
"Facilities"; plus I don't know who any of this is to be provided to?

"Tracking" is defined using the following:
#1 - To follow the tracks of...
#2 - To move over or along...
#3 - To observe or monitor the course of...
#4 - To observe the progress of...

"Tracing" is defined using the following:
#1 - A path or trail that has been beaten out by the passage of animals or 
people
#2 - To locate or discover by searching or researching evidence
#3 - To draw (a line or figure)
#4 - To follow the course or trail of...

so, you want a requirement that follows or moves or observes the path of or 
discovers by searching one or more "facilities". I'm confused. Please help. 
Especially with your next line:

"This include all routing entities as well as all signaling entities."

By "Routing entities" I assume you mean packet routers (L3 Routers)?
By "signaling entities" I assume you mean packet directors (like SIP Proxies)?

Req 3.1-2 "Each element in the signaling and routing paths solution shall 
maintain call detail records that can be accessed by mgmt systems to 
develop call statistics in real time."

 From this I assume you saying all SIP Proxies have to be dialog stateful 
*and* have an open TCP socket to communication mgmt information to some 
centralized server. Do you think that a Cisco, a Boeing or a Ford Motor 
company IT department is going to open up this pinhole from their servers 
to a local safety authority "in real time" no less?

Real time in voice is 50 packets a second. Do you need this level of 
communicate to CDR records from *every* server?

BTW - what's the definition of an "element"? Is it limited to a SIP (or 
v/v/im based) element, or does this include access to a CLI or network mgmt 
platform of all routers the packet happened to traverse?

Req 3.1-5 define what a congestion control is. Is it at layer 1,2,3,5 
and/or 7? In signaling or media packets? Layer 7 congestion controls can be 
done with redirects and automated session forwards, but at layer 3 you'll 
probably run into some problems without an interface being down.

Req 3.1-7 - what's an MSC? You don't have an acronym section in this doc 
prior to this acronym.

And, this req isn't an IETF issue other than to specify that a GW of 
whatever type converts an inbound call set-up to the appropriate signaling 
protocol to meet the other requirements. So this req should be removed.

Req 3.1-8 talks about peak load call set-up time and the use of CAMA 
circuits. Are you considering the peak load of every signaling element in 
the path all at once or individually?  Specifying anything about CAMA 
circuits is out of scope.

Req 3.2-5  how does a UA determine which LO it transmits is the most 
accurate? Doesn't it take whatever is currently available as is and 
transmit it?

Req 3.2-8 and 3.2-9 Please define what "default location" is. A UA likely 
has *a* location. How can that be determined to be default or not by the UA?

Req 3.3-1 Is (or can) this call back URI a AOR, a GRUU or a tel:uri? And if 
it is one of these, what do you want done with it (i.e. any special handling)?

Req 3.4.1 This doesn't have anything to do with identification of an 
emergency call or the routing of that call, therefore this is out of scope 
of this WG.

Req 3.4-2 This doesn't have anything to do with identification of an 
emergency call or the routing of that call, therefore this is out of scope 
of this WG.

Req 3.4-3 This doesn't have anything to do with identification of an 
emergency call or the routing of that call, therefore this is out of scope 
of this WG.

Req 3.4-4 This doesn't have anything to do with identification of an 
emergency call or the routing of that call, therefore this is out of scope 
of this WG.

Req 3.4-5 This doesn't have anything to do with identification of an 
emergency call or the routing of that call, therefore this is out of scope 
of this WG.

Req 3.4-6 This doesn't have anything to do with identification of an 
emergency call or the routing of that call, therefore this is out of scope 
of this WG.

Req 3.4-7 This doesn't have anything to do with identification of an 
emergency call or the routing of that call, therefore this is out of scope 
of this WG.
Section 3.5 "Validation of Civic Location" This doesn't have anything to do 
with identification of an emergency call or the routing of that call, 
therefore this is out of scope of this WG. This is good information to 
determine, but it has no place here.

Req 3.6-2 and 3.6-3 should be combined, as one if the follow-on of the other.
Req 3.6-4 "It must be possible for a designated 9-1-1 authority for a PSAP 
to approve of any geo-coding database used to assist in determining routing 
of calls to that PSAP."

An authority validating a database? This is out of scope of this WG.

Req 3.6-5 "It must be possible for the designated 9-1-1 authority to 
supply, maintain, or approve of databases used for civic routing. "

An authority supplying a database? maintaining a database? approving a 
database? This is out of scope of this WG.

BTW - what's the difference between an authority validating a database and 
approving a database? These are in 2 consecutive requirements.

Req 3.6-6 'conversion of geo formats' is out of scope of this WG

Req 3.6-9 doesn't make sense. Each element is going to use what needs.

Req 3.6.11 assumes the UA has the key only. This doesn't seem like it will 
create interoperability (having two routing systems), it seems like this 
will create interoperability problems (where one element uses one method 
and another uses the other).

3.6-13: "It must be possible for a given PSAP to decide where its calls 
should be routed." Where is this done, in DNS? or is this req referring to 
the PSAP having the ability to do with the inbound call what it wants (when 
it arrives)?

I'm getting tired is seeing references to "req ?". Do I the read have to 
figure this out?

Also, there are a lot of Bill-characters. That needs to be fixed.

3.6-15: "Routing as specified in Req ? may change on short notice due to 
local conditions, traffic, failures, schedule, etc." This isn't a 
requirement, so it should be removed.

3.6-17: "Routing information must be secured against unauthorized 
modification." Is this req referring to the routing database? Is that an IP 
problem? If not, this is out of scope for this WG and should be removed.

Req 3.6-18 through 6-201 talk about "contingency routing". Adding more than 
one URI destination for a PSAP, and then complicating that with a different 
URI per failure scenario within a proxy is making the Proxy's routing 
database (per proxy, that is) fairly complicated; perhaps unnecessarily so. 
I'm wondering how this can be maintain "only by higher level civic 
authorities" from Req 3.6-14 and expect to scale and be true all the time 
(3600x24x7)?

3.6-21: "A procedure must be specified to handle ôdefault routeö capability 
when no location is available or the location information is corrupted." 
How exactly does my UA (which just called 911) know what its default route 
is? Or for that matter, how does a proxy know how to route the call is the 
location data has been corrupted? The UA doesn't do anything other than 
indicate the session is an emergency call (with sos@ perhaps) and include a 
PIDF-LO. The UA doesn't do anything else except wait for the 200 OK (best 
case), right?

3.6-22: "Location available at the time the call is routed may not be 
accurate.  Updates to location may result in a different route and the 
system must accommodate this."

I don't know how a system can determine if a location is or is not 
accurate, so this req should be removed. Further, the INVITE will be routed 
how the routing database says it should be routed, regardless of how long 
ago the database was updated.

3.6-24: "Access Infrastructure providers must provide a location object 
that is as accurate as possible when location measurement or lookup 
mechanisms fail."

This is calling for "adding a (location) message body to a message", and is 
illegal in SIP at this time.

3.6-25: "Entities routing emergency calls shall retain information used to 
choose a route for subsequent error resolution." Is this asking that 
Proxies be transaction or dialog stateful?

Req 3.7-1 If there is connectivity and a path, why wouldn't the message be 
routed appropriately? This req should be removed.

Req 3.8-1 "There shall be no single point of failure" this is unattainable, 
therefore it should be removed

3.8-2: "Each subsystem in the i3 solution shall be designed such that the 
system survives major disruption including disaster, deliberate attack, and 
massive element failure."

This is an architectural requirement, which is not per of the charter of 
this WG, therefore this req should be removed.

3.8-3: "Special consideration should be given to ôDistributed Denial of 
Serviceö attacks"

This is an architectural requirement, which is not per of the charter of 
this WG, therefore this req should be removed.

3.8-5: "Mechanisms must be provided to provide constant verification of 
service availability to the PSAP."

Meaning my phone has to maintain TCP connectivity to a PSAP at all times? 
Is this expected to scale? And, is this expected to matter to Joe Citizen?

3.8-6: "Mechansism must be provided to provide automatically generated 
misroute and location error reports." From where to where?

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 9 Mar 2005 11:13:33 -0500

Thanks for all the comments James.  Comments inline

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> James M. Polk
> Sent: Tuesday, March 08, 2005 11:20 PM
> To: [email-masked]'
> Subject: [Ecrit] draft-rosen-nena-ecrit-requirements-00 Review
> 
> Brian/Nadine
> 
....snip...
It means that you need to know what elements the call traversed, and you
need to know what they did with them.  It needs to go with the call, so that
if something goes wrong, the PSAP can call on the right parties to figure
out what happened and how to fix it.

Part of this could be something like SIP Via headers.
Part of this could be the History header.

> By "Routing entities" I assume you mean packet routers (L3 Routers)?
No, we mean call routing entities. They may or may not be in the call
signaling path.

> By "signaling entities" I assume you mean packet directors (like SIP
Yes

> to a local safety authority "in real time" no less?
It isn't necessary to be dialog stateful, since you have dialog identifiers
that can correlate separate actions taken by a signaling element.

It doesn't say who has the management system, and in particular doesn't say
that the management system is in the public safety system.  If a carrier or
enterprise is in the path, and we can determine that they are in the path,
then we can communicate with them.  Don't need interconnection of management
systems.

> communicate to CDR records from *every* server?
No

> platform of all routers the packet happened to traverse?
SIP level is what we are thinking, not routers

> probably run into some problems without an interface being down.
Yeah, need more work here.  I think we're thinking this is all SIP level or
equivalent

> Req 3.1-7 - what's an MSC? You don't have an acronym section in this doc
Okay, sorry.  "Mobile Switching Center"

> protocol to meet the other requirements. So this req should be removed.
Nope, it says you have to make this work when calls originate on gateways.
That means there has to be A WAY to handle the location related data, and
the routing data, when calls originate in the PSTN (or a mobile network).
It may have implications on how routing is done.

> circuits is out of scope.
May need more discussion.  I personally think you consider peak load within
a domain.  The CAMA discussion was to forestall anyone objecting that if
there is a CAMA link in the path, you can't meet it.  Probably true that
ecrit can only consider the IP part of the path.

> accurate? Doesn't it take whatever is currently available as is and
This is part of a complex problem we have also raised in geopriv.
We need a very well defined solution so that routing elements can decide
what to do.  If it gets two locations, it needs to have a really simple way
to decide what to base routing decisions are.  If multiple location transit
the system, we need to know what they mean in a way that lets the PSAP make
quick, appropriate decisions.  There ARE reasonable circumstances where
there are multiple locations, as well as multiple representations of the
same location.  We have to have ways of keeping these things straight, and
not ask elements to have complex logic to figure it out.

> has *a* location. How can that be determined to be default or not by the
Use a cablemodem as an example.  We need mechanisms that would locate a
specific cablemodem to a specific street address.  Suppose something fails,
and we can't figure out what the address is.  We know the service area the
CMTS serves.  We can route based on that; say to resolution of a city.
The "default location" is the area served by the CMTS.

> it is one of these, what do you want done with it (i.e. any special
I think this is somewhat system dependent.  It's a URI of some form, and it
has to get to the device that called.  So, a GRUU may be appropriate in some
circumstances.  In others, an AoR or a tel would be appropriate.  What you
care about is if the call is terminated, and you want to call back the
party, a call placed to that URI will get the guy who called back.  

> emergency call or the routing of that call, therefore this is out of scope
ECRIT is going to have to deal with databases that provide routing and
validation of locations.  We need hooks in those databases for additional
information.  That makes it in scope.

If it's out of scope, where is it in scope?
...snip of similar questions and responses...

> determine, but it has no place here.
Nope.

It has to do with routing of the call.  You MUST validate location BEFORE
you route.

This is a fundamental requirement we have for processing of emergency calls.

You cannot route a location that is not in the routing database.   You need
to know that before you are called upon to route.

> Req 3.6-2 and 3.6-3 should be combined, as one if the follow-on of the
I hadn't realized this was a requirement of requirements documents.
There are two ideas here.  One is that you can route on either.
The other is that you must not require conversion.
Happy to reword if the current wording confused you.

> An authority validating a database? This is out of scope of this WG.

Nope.  We're defining this database here.  We need to provide mechanisms to
make the database accurate.  Might need signatures, for example.

> database? This is out of scope of this WG.
Maybe; depends on how the database is organized and who does it.

> approving a database? These are in 2 consecutive requirements.
Two different databases.  One is a geocoding database, the other is a
routing database.  We probably could tighten up the wording tho, since
validate/approve is the same thing.

> Req 3.6-6 'conversion of geo formats' is out of scope of this WG
Well, it’s the formats that we need standardized.  If its out of scope here.
where is it in scope?

> Req 3.6-9 doesn't make sense. Each element is going to use what needs.
The issue here is that in Sweden, you route based on county code.  In some
parts of the U.S, which side of the street you are on matters.  This
requirement says you can't assume that routing granularities are the same
everywhere.  I think that is a valid requirement.

> and another uses the other).
No, it says that all routing elements must have access to both, and must be
able to route on either.

It's not possible to have one, unless we bite a very large bullet and demand
accurate geocode databases be created everywhere.
> the PSAP having the ability to do with the inbound call what it wants
No, it means it must have the ability to specify the route (that which is
retrieved from the database).  It's a data ownership and authority issue.
I think it turns into what Request URI is pulled out of the database.

> I'm getting tired is seeing references to "req ?". Do I the read have to
Sorry, my fault.  I'll fix this.

> Also, there are a lot of Bill-characters. That needs to be fixed.
Yes.  Don't know how I got them.

> requirement, so it should be removed.
I can reword it, but the point is that you can't determine a route at, say,
boot time, if you assume systems can stay up for months.

> problem? If not, this is out of scope for this WG and should be removed.
The routing database is going to get specified here.  It needs controls on
unauthorized modification.  What part of that is controversial?

> authorities" from Req 3.6-14 and expect to scale and be true all the time
When you have more than one contingency route intended for the same
circumstances, you try them one at a time until you get through.  Having
different contingencies for different circumstances implies we need some
kind of labeling. I don't think its more complex than that.

> PIDF-LO. The UA doesn't do anything else except wait for the 200 OK (best
Well this gets to the possibility of multiple locations (a default and an
actual).  If the location has some integrity protection, or when you look it
up in the routing database you don't find it (despite validation), you need
a default route.

> ago the database was updated.
We need to be able to do this.  It may be trivial as long as the destination
can reroute.

> illegal in SIP at this time.
No, this means that operationally, you always get a location, even if your
primary location determination mechanism fails.  The AIP is at the beginning
of the process, not in the middle.

> Proxies be transaction or dialog stateful?
Nope.  It means they retain the info they had when they routed, and what
they did.

> routed appropriately? This req should be removed.
This depends on how the system is designed.  This says you should not depend
on intermediaries that can fail.

> therefore it should be removed
Disagree.  Within the scope of the work, the system should be designed so
that every element can be redundant.  That is reasonable.  As an example, we
need to have multiple copies of databases.

> this WG, therefore this req should be removed.
I disagree strongly.

This says we should have a bias to choose solutions that are known to be
very reliable in the face of massive failure.  We have experience with many
subsystems in the Internet that have this characteristic.  We should use
them, rather than design new ones that might or might not have such
characteristics.   This says that DoS is a certainty, and we have to design
systems to be very resilient to such attacks.  This says that we really care
about the integrity of data used in the system, and it must be hardened
against deliberate forgery or attempts to misroute calls.

> this WG, therefore this req should be removed.
Huh?

This system is going to be a prime DoS target.  Having a requirement that
highlights that fact is pretty reasonable I think.

While every system should be hardened against DDoS, this system is
particularly vulnerable.  I expect exhaustive analysis of this issue in the
security session of the resulting work.
> Is this expected to scale? And, is this expected to matter to Joe Citizen?
No, it means that we need ways to determine that the system is working.  You
want that to be proactive; before calls fail.  The mechanisms must support
ways to do that.  It might be trivial, it might be hard.  Depends on what
the solution looks like.

>From the routing elements.  To is an area that needs some work.  Ultimately,
the PSAP, but it might need some structure to get it there.

Brian