Subject: [dhcwg] RE: [Ecrit] draft-polk-dhc-uri-00

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Wed, 14 Sep 2005 11:11:37 -0400

Brian,

First, PSAPs should have operational constraints to migrate operations
gracefully so they can not arbitrarily change mappings at a faster pace
than say 24 hours.

Second, disaster-related effects should be handled by proper high
availability design.  Non-respone from the primar PSAP URI should result
in fail-over to an alternate IP address located in a different
geographic area.  What is invalid here is not the URI but the underlying
PSAP network design.

And yes, the client should have some maximum time beyond which it must
refresh.  But, it might also be more predictable for the voice system if
the network managed when the refreshes occurred before the deadline such
that there is no avalanche from clients.  Thus, clients would always
find themselves inside that (24 hour?) window.

Mike

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Brian Rosen
> Sent: Wednesday, September 14, 2005 9:07 AM
> To: Marc Linsner (mlinsner); James Polk (jmpolk)
> Cc: [email-masked]; 'ECRIT'
> Subject: RE: [Ecrit] draft-polk-dhc-uri-00
> 
> I've previously argued that while getting it when you boot 
> (i.e. run DHCP) is a good idea, it would be best if you did 
> the mapping from location to URI just before the call, 
> because, due to failures or other disaster related effects, 
> the mapping may have changed.  It IS a transaction you want 
> to do when you want to make a call setup, because you want 
> the most recent data.
> 
> You also want to make certain that you refresh this data periodically.
> Daily is probably the minimum, and you know that some DHCP 
> lease times are on the order of weeks.
> 
> So, I would like this wording significantly changed.
> 
> Brian
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Marc Linsner
> Sent: Wednesday, September 14, 2005 8:48 AM
> To: 'James M. Polk'
> Cc: [email-masked]; 'ECRIT'
> Subject: [Ecrit] draft-polk-dhc-uri-00
> 
> James,
> 
> Would you please provide the basis for your text below 
> regarding the timing of psap determination, I can't seem to 
> match it up with any of the requirements within ecrit or geopriv.
> 
> "One example of this URI download would be one specifically 
> for the SIP or SIPS URI of the appropriate Public Safety 
> Answer Point (PSAP) for the client when the user of that 
> client calls for emergency help (911 or 112-type of help).  
> This is not a transaction that should take place when a voice 
> application wants to make such a critical call set-up.  It is 
> more appropriate that this information be downloaded to the 
> client when the voice (or other) application boots up in case 
> it is needed at a later time."
> 
> Thanks,
> 
> -Marc-
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 
> 
> 
> _______________________________________________
> Ecrit mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ecrit
> 

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

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 14 Sep 2005 11:29:23 -0400

Michael

I'm not sure what your experience is.  Mine is that disasters don't go
according to plan.  You plan for disasters, and then you deal with what
actually happens.  Often, what you thought would work, doesn't.

You are making an assumption that the URI you get from mapping is always
good for, say, 24 hours, and any problems encountered can be solved by
changing the resolution of the URI.  I'm not so sure.  

Maybe we do want all calls that were going to a specific URI to go somewhere
else.  Maybe we want to change routing of some of them.  Maybe we are
unable, for some reason, to change the resolution of the URI. 

It's probably true that a 24 hour old mapping will work in most cases.  I'm
pretty unhappy with "probably" and "most", because of the consequences of
getting wrong and the uncertainty of being able to manipulate a limited
number of levers when lots of infrastructure is failing.  This whole subject
is about probabilities of getting the right thing to happen, and I think we
should take every opportunity to improve the odds.  

Brian

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]] 
Sent: Wednesday, September 14, 2005 11:12 AM
To: [email-masked]; Marc Linsner (mlinsner); James Polk (jmpolk)
Cc: [email-masked]; ECRIT
Subject: RE: [Ecrit] draft-polk-dhc-uri-00

Brian,

Mike