Subject: RE: [Ecrit] WG: Action items needed for I-D:draft-schulzrinne-ecrit-requirements-00.txt

From: "Roger Marshall" <[email-masked]>
Date: Wed, 29 Jun 2005 22:58:57 -0700

Hi.
To send out an updated version (-01) of the ecrit requirements I-D, requires that I follow up on a few outstanding action items which call for rewritten text (ref: interim meeting 5/18 email update at bottom).

The updated I-D will be posted once I get (agreed-to) responses based on the following listing.

1. Items that I show still outstanding (need proposed text to be submitted  to ecrit mail-list):

R5 - Keep (Henning to rewrite text)
A1 - Keep (possible reword of A1, may split into two separate requirements) [Needs owner]
A3 - Keep (reword along with A1 into two separable requirements) [Needs owner]
A6 - Keep (possible reword per Ted Hardie composed text)
L10 - Keep (Hannes to lead further investigation w/Nadine, Ted)
I9 - Keep (rewrite, Henning to send text)
D5 - Keep (rewrite, Marc Linsner to send text as, "to specify minimize number of round trips rather than minimizing time")
D9 - Keep (rewrite to include D8) [Needs owner]
SD1 - Keep (rewrite, Tom Taylor to send extensibility requirement)

2. Action items completed (no action required):

R6 - Keep (Ted Hardie to send candidate text as replacement for R6) [Done, ref: Hardie email 5/17]
L6 - Keep (Nadine to supply additional text) [Done, ref: Nadine email 5/18]
L9 - Keep (Nadine to rewrite, for clarity to say "as input to the mapping protocol" [Done, ref: Nadine email 5/18]
L28 - Keep (James Polk to provide reworded text) [Done, (reworded per supplied text) ref. Polk email 5/14]
I1 - Keep (reword as "Calls Must be routed to the PSAP responsible for this particular geographic area") [Done.]
I3 - Keep (rewrite, Henning will send text) [Done, ref: Henning email 5/18, and Andrew email 5/25]
I4 - Keep (rewrite, Henning and Patti McCalmont to collaborate on text) [Done, ref: Henning email 5/18]
I7 - Keep (rewrite, Brian Rosen to send text) [Done, ref: Rosen email 5/18]
I8 - Keep (rewrite, Henning to send text) [Done, ref: Henning email 5/18]
I10 - Keep (Brian to rewrite as standalone requirement) [Done, ref: Rosen email 5/18]
I25 - Keep (to be rewritten by Henning) [Done, ref: Henning email 5/18]
I31 - Keep (rewrite, Ted Hardie to send text) [Done, ref: Hardie email 5/18]
D1 - Keep (rewrite, Henning to send text) [Done, (incl. as modified by Ted) ref: Henning & Ted email, both 5/18]
D7 - Keep (rewrite, Henning to send text) [Done, ref: Henning email 5/18]

3. Other changes made:

a. I13 [Replacement for original I13 (this had been marked "delete", but received submitted text from Brian email 5/18)]

b. L31 [New, added per Henning email 5/21, "Split Responsibility"]

c. L32 [New, per following note] Note: based on discussion around L13, Brian Rosen to write a new requirement to say that mapping function must be independent of the call (and at the time of the call) [Done, ref. Rosen email 5/17]

d. Consolidated variety of terms, including ECC, iPSAP, IP-PSAP, PSAP into a single term, "PSAP".  
 1. I chose to leave the term "ECC" in the Terminology section without change, though it is no longer referenced in the I-D.
 2. Deleted term iPSAP from terminology section, and merged its definition in with definition for PSAP.

e. James Polk submitted email on 5/10 (114 comments), which I will reply to with itemized responses to for each of the comments.  Many of these are simple editorial fixes (which I appreciate), others may need to go to the list, since we didn't have time to cover the complete list at the last interim.

Thanks.
Roger Marshall

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Roger Marshall
Sent: Wednesday, May 18, 2005 12:22 PM
To: [email-masked]
Subject: RE: [Ecrit] WG: Updated Req Review ofI-D:draft-schulzrinne-ecrit-requirements-00.txt

All:
RE: ECRIT REQUIREMENTS REVIEW UPDATE:

Below is a completed disposition status listing of ALL ecrit (I-D) requirements, based on continued (5/18) interim ecrit meeting this morning.

These results are associated with review of requirements listed in: 

draft-schulzrinne-ecrit-requirements-00.txt

3 categories (with qualifiers) of disposition are:
1. Keep (as written, or with required changes to text)
2. Move (into another <named> document)
3. Delete (remove, possibly merge into other requirement)

Note:
Original requirement numbers will not be reused.  New requirements will be added onto the end of each section (in the next revision of the I-D).

3.  High-Level Requirements
R1 - Keep
R2 - Keep
R3 - Keep
R4 - Keep
R5 - Keep (Henning Schulzrinne to rewrite text)
R6 - Keep (Ted Hardie to send candidate text as replacement for R6)
R7 - Delete

4.  Emergency Address
A1 - Keep (possible reword of A1, may split into two separate requirements)
A2 - Move (Jon Peterson will advise Henning on destination for A2)
A3 - Keep (reword along with A1 into two separable requirements)
A4 - Keep
A5 - Delete
A6 - Keep (possible reword per Ted Hardie composed text)
A7 - Delete

5.  Identifying the Caller Location
L1 - Move (L1, L2, & L3 to be put into a new document (to be created by James Polk) with the goal of becoming an Informational RFC
L2 - (see L1)
L3 - (see L1)
L4 - Move (into the Information doc)
L5 - Move (Patti McCalmont to rewrite, consolidate with L11, move into the Information doc)
L6 - Keep (Nadine Abbott to supply additional text)
L7 - Delete (out of scope)
L8 - Delete (out of scope)
L9 - Keep (Nadine to rewrite, for clarity to say "as input to the mapping protocol"
L10 - Keep (Hannes Tschofenig to lead further investigation w/Nadine, Ted)
L11 - Move (see L5)
L12 - Delete (out of scope)
L13 - Move (into the Information doc)

Note: based on discussion around L13, Brian Rosen to write a new requirement to say that mapping function must be independent of the call (and at the time of the call)

L14 - Delete (out of scope)
L15 - Delete (out of scope)

Note: based on discussion around L15, Brian Rosen to write a new requirement re: default routing

L16 - Delete (out of scope), (geopriv)
L17 - Delete (out of scope)
L18 - Delete (out of scope), (geopriv)
L19 - Delete (out of scope), (geopriv)
L20 - Delete (already discussed)
L21 - Move (into Informational doc)

[start of 5/18 discussion]

L22 - (Change to:) Move (to Informational doc/BCP) 
L23 - Delete
L24 - (Change to:) Move (to Informational doc/BCP)
L25 - Move (into Informational doc)
L26 - Delete (out of scope)
L27 - Delete (out of scope)
L28 - Keep (James Polk to provide reworded text)
L29 - Delete (out of scope)
L30 - Delete (out of scope, covered elsewhere)

6.  Identifying  the Appropriate Emergency Call Center

Note 1: Delete following paragraph from text block:
   "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."

Note 2: Consolidate following terms (throughout document):  ECC; iPSAP, IP-PSAP all become one term, PSAP.

I1 - Keep (reword as "Calls Must be routed to the PSAP responsible for this particular geographic area")
I2 - Move (into Informational doc)
I3 - Keep (rewrite, Henning will send text)
I4 - Keep (rewrite, Henning and Patti McCalmont to collaborate on text)
I5 - Delete (out of scope)
I6 - Delete (out of scope)
I7 - Keep (rewrite, Brian Rosen to send text)
I8 - Keep (rewrite, Henning to send text)
I9 - Keep (rewrite, Henning to send text)
I10 - Keep (Brian to rewrite as standalone requirement)
I11 - Delete (out of scope)
I12 - Move (to Informational doc)
I13 - Delete (out of scope)
I14 - Delete (redundant, mapping can be done based on any PIDF-LO field (see L9)
I15 - Move (to Informational doc)
I16 - Move (to Informational doc)
I17 - Move (to Informational doc)
I18 - Move (to Informational doc)
I19 - Move (to Informational doc)
I20 - Move (to Informational doc)
I21 - Delete (per rewritten I3/I4 by henning)
I22 - Move (to Informational doc)
I23 - Delete
I24 - Delete
I25 - Keep (to be rewritten by Henning)
I26 - Move (to Informational doc)
I27 - Move (to Informational doc)
I28 - Move (to Informational doc)
I29 - Delete
I30 - Move (to security document as an update)
I31 - Keep (rewrite, Ted Hardie to send text)
I32 - Delete
I33 - Delete
I34 - Move (to Informational doc)
I35 - Delete (merged into I31)
I36 - Move (to Informational doc, merge with Traceability)
I37 - Delete (out of scope)
I38 - Delete
I39 - Delete (merge with L13)

7.  Emergency Address Directory
D1 - Keep (rewrite, Henning to send text)
D2 - Move (to security doc)
D3 - Move (to security doc)
D4 - Delete (out of scope)
D5 - Keep (rewrite, Marc Linsner to send text as, "to specify minimize number of round trips rather than minimizing time")
D6 - Delete (already covered in rewritten I3/I4 by Henning)
D7 - Keep (rewrite, Henning to send text)
D8 - Move (combine with D9) & Delete Motivation text
D9 - Keep (rewrite to include D8)

8.  Identifying the Caller
C1 - Move (to Informational doc)
C2 - Move (to Informational doc)
C3 - Move (to Informational doc)

9.  Call Setup and Call Features
S1 - Move (to security doc)
S2 - Move (to informational doc)
S3 - Delete
S4 - Move (to security doc)
S5 - Move (to informational doc)
S6 - Delete
S7 - Move (to informational doc)
S8 - Move (to informational doc)
S9 - Delete (collapses into tracking and tracing I7)

10.  Supplemental Information
SD1 - Keep (rewrite, Tom Taylor to send extensibility requirement)
SD2 - SD9 Delete (merge into rewritten SD1, above)

11.  Security Considerations
SEC1 - Move (to security document/discussion)
SEC2 - Move (to security document/discussion)
SEC3 - Move (to security document/discussion)

[end of ecrit requirements I-D discussion for 5/18]

Per chairs' instruction, please post rewrites (where noted) onto the list for discussion by wg.

Regards,

Roger Marshall

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tschofenig Hannes
Sent: Friday, May 06, 2005 1:39 PM
To: [email-masked]'
Subject: [Ecrit] WG: I-D ACTION:draft-schulzrinne-ecrit-requirements-00.txt

hi all, 

this document is an attempt to consolidate the requirements of the
individual documents into a single document. as indicated at the ecrit
working group meeting henning's document was used as the starting point. 
the draft authors of the other requirements documents have tried to
determine whether their requirements are already covered by henning's
document. roger incorporated them if they weren't. roger also clean up the
terminology and removed non-relevant parts. thanks for the good work, roger.

please review the document carefully. we will spend some time at the interim
meeting to discuss the open issues. 

ciao
hannes

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im
Auftrag von [email-masked]
Gesendet: Freitag, 6. Mai 2005 21:44
An: [email-masked]
Betreff: I-D ACTION:draft-schulzrinne-ecrit-requirements-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Requirements for Emergency Context Resolution 
			  with Internet Technologies
	Author(s)	: H. Schulzrinne, R. Marshall
	Filename	: draft-schulzrinne-ecrit-requirements-00.txt
	Pages		: 38
	Date		: 2005-5-6
	
This document enumerates requirements for emergency calls placed by
   the public using voice-over-IP (VoIP) and general Internet multimedia
   systems, where Internet protocols are used end-to-end.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-schulzrinne-ecrit-requirements-00.
txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the
message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-schulzrinne-ecrit-requirements-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-schulzrinne-ecrit-requirements-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jun 2005 15:49:12 -0400

Here's a proposal:

R5.  Minimum Connectivity

An emergency call should succeed as long as there is a working network 
path between the caller and the PSAP. In particular, reliance during 
call set-up and calls on entities and network paths that are located 
elsewhere should be minimized.

Example: A caller in New York who needs to contact a PSAP in the same 
city shouldn't have to get information from some entity in Texas to make 
that call, as the call would then fail if the New York to Texas path is 
unavailable. (To avoid this, the caller could, for example, have cached 
mapping information, use a local server that has the necessary 
information, or use other mechanisms to avoid such off-path dependencies.)

I hope this is clearer.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jun 2005 15:50:18 -0400

This is actually closely related to R5 and essentially captures the same 
requirement.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 30 Jun 2005 16:02:19 -0400

Is the PSAP running the mapping service?  Because that is what this  
seems to require.

Perhaps what you are really getting at is that no jurisdiction should  
be forced to rely on a mapping service they do not control.

-andy

On Jun 30, 2005, at 3:49 PM, Henning Schulzrinne wrote:

> Here's a proposal:
>
> R5.  Minimum Connectivity
>
> An emergency call should succeed as long as there is a working  
> network path between the caller and the PSAP. In particular,  
> reliance during call set-up and calls on entities and network paths  
> that are located elsewhere should be minimized.
>
> Example: A caller in New York who needs to contact a PSAP in the  
> same city shouldn't have to get information from some entity in  
> Texas to make that call, as the call would then fail if the New  
> York to Texas path is unavailable. (To avoid this, the caller  
> could, for example, have cached mapping information, use a local  
> server that has the necessary information, or use other mechanisms  
> to avoid such off-path dependencies.)
>
> I hope this is clearer.
>
>
> Roger Marshall wrote:
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jun 2005 16:11:58 -0400

> Is the PSAP running the mapping service?  Because that is what this  

Not at all. You could imagine a server run by my ISP or my IT department 
(for an enterprise) that does the mapping. If it caches the relevant 
mapping entries, short-term disruptions of network connectivity from 
that ISP, say, to other places do not affect the mapping. The mapping 
service could be co-resident with the local outbound proxy, but doesn't 
have to be.

There will be cases where this local mapping server doesn't have the 
mapping (say, I dial in from Uganda via a VPN and I've never dialed 
9-1-1 from Uganda before), but those cases should be relatively rare. 
That's why I used the softer "should", rather than "must".

I'm also not worried about long-term (days, weeks) outages. If the whole 
Internet is down for a week, there are likely going to be bigger 
problems than VoIP access to 911.

Having it be run by the PSAP wouldn't help at all - the caller, by 
definition, doesn't know the PSAP, so it wouldn't know how to get there. 
("Chicken-egg" and all that.)

> be forced to rely on a mapping service they do not control.

Not really. I hope the above makes this clear. Caching is key here.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 30 Jun 2005 16:30:00 -0400

On Jun 30, 2005, at 4:11 PM, Henning Schulzrinne wrote:
> You could imagine a server run by my ISP

You've just made an assumption that the path to an ISPs servers is a  
subset of any outbound path.  This is not always true.

> If it caches the relevant mapping entries

What are the relevant mapping entries?

> Caching is key here.

If this requirement is about caching, then it should be clear that it  
is about caching.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jun 2005 16:38:48 -0400

> subset of any outbound path.  This is not always true.

Certainly, but usually closely correlated. Imagine colocating this 
server with the ISPs DHCP or DNS servers. You aren't going to be doing 
much VoIP of any kind if those are unreachable...

> What are the relevant mapping entries?

Those serving its local customers. Except for VPNs, the coverage region 
of most ISPs is fairly limited in geography.

> If this requirement is about caching, then it should be clear that it  

This is one particular solution; I didn't want to be solution-specific, 
but if nobody objects, making it more specific clearly helps.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 30 Jun 2005 17:00:13 -0400

On Jun 30, 2005, at 4:38 PM, Henning Schulzrinne wrote:

>> You've just made an assumption that the path to an ISPs servers is  
>> a  subset of any outbound path.  This is not always true.
>>
>
> Certainly, but usually closely correlated.

So what's the point of this being a requirement if there are many  
situations where it is not applicable?

> Imagine colocating this server with the ISPs DHCP or DNS servers.

Imagine business-class DSL where you don't care about either.

> Those serving its local customers. Except for VPNs, the coverage  
> region of most ISPs is fairly limited in geography.

What is the data in those entries?  What are the keys and what are  
the values?

> This is one particular solution; I didn't want to be solution- 
> specific, but if nobody objects, making it more specific clearly  
> helps.

It doesn't.  Perhaps we should start with the functional requirement  
before working on the solution.  This requirement sounds like you  
have a solution looking for a problem.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jun 2005 17:33:23 -0400

> situations where it is not applicable?

Your and my perception may differ, but I still believe that the 
requirement is a valid one, for robustness purposes in times of network 
and infrastructure stress, and that this can be readily accomplished in 
the vast majority of today's network infrastructure. Yes, there will be 
cases where it isn't possible, but we're designing protocol 
requirements. Thus, I want to require from the protocol design that 
willing ISPs can easily offer such robustness to their customers. If the 
protocol doesn't support this readily, it can't be offered at all.

> What is the data in those entries?  What are the keys and what are  the 
> values?

I'm not sure I understand the question. Could be either individual 
entries (one street address) or, for geographic entries, regions (polygons).

>> specific, but if nobody objects, making it more specific clearly  helps.
> 
> 
> before working on the solution.  This requirement sounds like you  have 
> a solution looking for a problem.

The functional requirement is as originally stated: Only require that 
the two end systems and closely related entities need to be involved. 
You could call this an instance of the fate-sharing design principle for 
the Internet.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 30 Jun 2005 17:57:37 -0400

On Jun 30, 2005, at 5:33 PM, Henning Schulzrinne wrote:
>> What is the data in those entries?  What are the keys and what  
>> are  the values?
>>
>

And what good is caching this?  If I've never made an emergency call  
from 234 Maple Dr., it won't be cached.  If a call has never been  
made at the x,y,z coordinates for the shrubs in my front yard, it  
won't be cached.  Just how often do you expect specific locations to  
be making emergency calls?

Also, the idea of having the polygons cached means that you are not  
worried about security of just anybody knowing those polygons.

> The functional requirement is as originally stated: Only require  
> that the two end systems and closely related entities need to be  
> involved. You could call this an instance of the fate-sharing  
> design principle for the Internet.

The problem with this (closely related entities) is that measuring  
such a requirement is very subjective.  If that is how you wish to  
measure them, then you ought to just say that the protocol be robust,  
efficient, and well engineered.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jun 2005 18:07:28 -0400

> from 234 Maple Dr., it won't be cached.  If a call has never been  made 
> at the x,y,z coordinates for the shrubs in my front yard, it  won't be 
> cached.  Just how often do you expect specific locations to  be making 
> emergency calls?

For geo, only region caching makes sense. For civic, the testing process 
you will need to do for address validation and other functions ensures 
that almost all addresses will be (or can be) cached, even if that 
residence has never dialed 9-1-1 before.

> worried about security of just anybody knowing those polygons.

That information is essentially public today, as it tends to conform to 
civic boundaries such as state, county or city lines. (It doesn't 
always, but you can almost always guess who will answer the 911 call 
today, at least with 50-50 odds.) I just visited the LAPD 911 center in 
downtown LA. They make no secret of their coverage region of about 4 
million people.

> The problem with this (closely related entities) is that measuring  such 
> a requirement is very subjective.  If that is how you wish to  measure 
> them, then you ought to just say that the protocol be robust,  

The requirement stated is far more specific than the general 
motherhood-and-apple-pie robustness requirements. This is why we're 
disagreeing :-)

---

From: Ted Hardie <[email-masked]>
Date: Thu, 30 Jun 2005 14:27:16 -0700

Henning's proposal is:

>R5.  Minimum Connectivity
>
>An emergency call should succeed as long as there is a working network path between the caller and the PSAP. In particular, reliance during call set-up and calls on entities and network paths that are located elsewhere should be minimized.
>
>Example: A caller in New York who needs to contact a PSAP in the same city shouldn't have to get information from some entity in Texas to make that call, as the call would then fail if the New York to Texas path is unavailable. (To avoid this, the caller could, for example, have cached mapping information, use a local server that has the necessary information, or use other mechanisms to avoid such off-path dependencies.)
>
>I hope this is clearer.

I think "working network path between the caller and the PSAP" isn't clear
enough.  Do you mean only that there is IP connectivity between the terminal
and the PSAP's IP address?  Taking SIP as the presumed contact method for
a moment, would that imply that the terminal should be able to connect
to the PSAP, even if its normal proxy is unavailable and the proxy for
the PSAP is also unavailable?  Or does the "working network path" imply that
the proxies configured for these are also up and available?

I'd also strongly suggest that "located elsewhere" mixes up network
topology with geography, which is one of our constant sources of
confusion.  Can you recast this in terms of network topology?

Something like:

R.5.

The ability to discover the correct PSAP should not require a level of connectivity
substantially beyond that which would be needed to contact that PSAP.  It is
not required that the servers used for discovery be on-path to the call flow,
but their reachability should be a strong consideration in devising deployment
strategies.

			regards,
				Ted

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jun 2005 21:56:21 -0400

> the proxies configured for these are also up and available?

Yes, "working network path" = "current IP connectivity" + "ability to 
route SIP calls via outbound proxy [if necessary] and PSAP proxy". The 
basic rule is simple:

"The look-up process should not add any additional network-related 
failure modes. In other words, if a caller knew the PSAP signaling 
address and can reach it via signaling and media, the usage of a mapping 
mechanism should not interfere with that reachability if network 
connectivity to parts of the mapping service is temporarily impaired."

> confusion.  Can you recast this in terms of network topology?

Agreed. Located elsewhere ==> maybe "located in parts of the network 
that are neither on the signaling nor media path from the caller to the 
PSAP". It's a bit longer...

> but their reachability should be a strong consideration in devising deployment

This is ok, although "call flow" is a bit mushy (and means something 
rather different in the SIP community, if you look at documents titled 
"call flows"). One could simply say "media and signaling path" instead. 
I believe these terms are widely understood, at least on the VoIP side 
of the world.

---

From: Andrew Newton <[email-masked]>
Date: Thu, 30 Jun 2005 22:37:14 -0400

On Jun 30, 2005, at 6:07 PM, Henning Schulzrinne wrote:

>> And what good is caching this?  If I've never made an emergency  
>> call  from 234 Maple Dr., it won't be cached.  If a call has never  
>> been  made at the x,y,z coordinates for the shrubs in my front  
>> yard, it  won't be cached.  Just how often do you expect specific  
>> locations to  be making emergency calls?
>>
>
> For geo, only region caching makes sense. For civic, the testing  
> process you will need to do for address validation and other  
> functions ensures that almost all addresses will be (or can be)  
> cached, even if that residence has never dialed 9-1-1 before.

Validation is not required everywhere.  From the reaction to it as a  
requirement, I got the impression that only the US does this.   
Regardless, it isn't fail-safe either.  I was told of an example  
where an old lady who lived in a house for a long time try to dial  
911 for the first time and couldn't because her line had never been  
validated.

Do these caches have timeouts?  If not, how do the entries get  
updated?  Are the caches big enough to hold all the information for  
the civic data?  How does that work for ISPs like Verizon or Comcast  
you serve millions of customers over vast geographic, multi- 
jurisdictional areas?  Are they expected to keep all the data for all  
the jurisdictions they serve cached all the time?

>> Also, the idea of having the polygons cached means that you are  
>> not  worried about security of just anybody knowing those polygons.
>>
>
> That information is essentially public today, as it tends to  
> conform to civic boundaries such as state, county or city lines.  
> (It doesn't always, but you can almost always guess who will answer  
> the 911 call today, at least with 50-50 odds.) I just visited the  
> LAPD 911 center in downtown LA. They make no secret of their  
> coverage region of about 4 million people.

At the interim meeting, Marc told me of a state where they did not  
want the information to be widely distributed below the state level.

It is also one thing to have public information that requires  
somebody to go down to the courthouse to find or do some digging to  
get, and quite another to have it accessible from anywhere on the  
Internet in a common format with a common protocol.

I'm sure some jurisdictions do not have these concerns, but that  
doesn't mean they all don't.

> but their reachability should be a strong consideration in devising  

I like this much better.

On Jun 30, 2005, at 9:56 PM, Henning Schulzrinne wrote:
> address and can reach it via signaling and media, the usage of a  
> mapping mechanism should not interfere with that reachability if  
> network connectivity to parts of the mapping service is temporarily  
> impaired."

What you are implying is that each ISP maintain and run a mapping  
server.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 30 Jun 2005 23:09:34 -0400

Andrew Newton wrote:

> Regardless, it isn't fail-safe either.  I was told of an example  where 
> an old lady who lived in a house for a long time try to dial  911 for 
> the first time and couldn't because her line had never been  validated.

That's fine; we're talking about increasing probability of success under 
adverse conditions. I would never claim that we can blow up the Internet 
to smithereens and still complete 100% of the 9-1-1 calls.

> updated?  Are the caches big enough to hold all the information for  the 
> civic data?  How does that work for ISPs like Verizon or Comcast  you 
> serve millions of customers over vast geographic, multi- jurisdictional 
> areas?  Are they expected to keep all the data for all  the 
> jurisdictions they serve cached all the time?

Let's take an estimate. There are about 120 million households in the 
US; let's assume that each has an entry size of about 100 bytes, which 
is larger than the maximum address size stipulated by the US Postal 
Service (64 bytes) and ignoring obvious data compression mechanisms, 
such as not storing "San Francisco" literally a million times. Makes 12 
GB of data, which is less than the smallest regular iPod holds, for 
$299. Or, if you'd like, is about $12 of disk storage at current IDE 
prices.

Thus, even if every Verizon POP in the US had cached the complete 
address table for the US, storage is going to be a trivial expense.

Geo is not much different, as the number of PSAP service regions is 
about 6000.

Clearly, caches have timeouts and need to be updated, but very slowly, 
since address-to-PSAP mappings don't change very frequently.

> 
> At the interim meeting, Marc told me of a state where they did not  want 
> the information to be widely distributed below the state level.

I'm sorry to say that the basic design of ECRIT makes hiding such 
information difficult, caching or not. Since doing the lookup does not 
require to actually place a 911 call, I can easily do mappings from any 
address I care to, at my leisure. I don't have to test all addresses, 
just a few to get a very good idea whether, say, my local PSAP serves 
the county or just one community.

> 
> It is also one thing to have public information that requires  somebody 
> to go down to the courthouse to find or do some digging to  get, and 
> quite another to have it accessible from anywhere on the  Internet in a 
> common format with a common protocol.

The digging in almost all places involves taking out the car atlas and 
looking for the county or city boundaries. You can also get this 
electronically courtesy of the Census (TIGER database).

We all agree that there are some oddities, due to rate center boundaries 
and other historical artifacts, but any attack potential presumably 
doesn't rely on the fact that one can get a complete mapping from every 
street, just from many such addresses. If we're relying on hiding PSAP 
(or PSAP aggregate) URLs to protect the 9-1-1 infrastructure, we might 
as well start selling snake oil.

Companies like MapInfo will also gladly sell you this information (we 
have used the product locally to do mappings <ad>Evinsa</ad>).

> doesn't mean they all don't.

Even if you could protect this somehow, this simply means that such 
jurisdictions would not get the benefit of fate sharing robustness. 
However, we're designing a protocol, so you are in effect arguing that 
nobody should since some might decide not to use it. I fail to see the 
logic of this.

> What you are implying is that each ISP maintain and run a mapping  server.

This shouldn't be required, but I think that if a lawyer looks at the 
liability, this will seem like a very cheap way to stay out of the 
evening news. Since the requirements don't prescribe network 
architecture, I simply want to make sure that the protocol mechanisms we 
design allow very distributed and localized resolution. It is then up to 
operational folks to decide whether servers are placed next to each DNS 
server, closer to the core or next to each outbound proxy in a VSP. 
Thus, it doesn't have to be each POP.

As a hypothetical design example, a system/protocol that relied on 
contacting a "root" server somewhere in some faraway network would 
probably fail to meet this requirement.