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

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

Brian,

My early experience is military.  You design networks with disaster in
mind.  You have a plan B...  and C, and D, and ...  We used to play war
games where we would arbitrarily knock out communications sites, and
then say, now what?  We would do this for single and multiple points of
failure.  Of course, there is a cost to having backups, but having no
plan or backups whatsoever is no plan at all, especially for emergency
aid organizations.

We have voice features that say, if you ring me in NY and don't get an
answer, ring me at this alternate site in Boston, all without changing
the called URI.  Such capabilities exist at multiple layers of the
protocols, we only need to use them.  Why would you assume that a PSAP
network would not be designed to take advantage of such capabilities?

Mike

> -----Original Message-----
> From: Brian Rosen [mailto:[email-masked]] 
> Sent: Wednesday, September 14, 2005 11:29 AM
> To: Michael Hammer (mhammer); Marc Linsner (mlinsner); James 
> Polk (jmpolk)
> Cc: [email-masked]; 'ECRIT'
> Subject: RE: [Ecrit] draft-polk-dhc-uri-00
> 
> 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,
> 
> 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