Subject: 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
> 

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

---

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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 15 Sep 2005 09:09:36 -0400

On Sep 14, 2005, at 11:29 AM, Brian Rosen wrote:

> number of levers when lots of infrastructure is failing.

Perhaps we should have a better understanding of what failures you  
are trying to avoid.  After all, if infrastructure is failing then  
that can mean much more than SIP proxies, it can mean copper and  
fibber being cut and all manner of problems.  If infrastructure is  
failing, it would seem that lower layer redundancies such as anycast  
might be more effective.

Before inflicting complexity on 99.99% of the cases for something  
that is only needed 0.01% of the time, there should be a better  
understanding of what failures are being mitigated.

-andy

---

From: John Schnizlein <[email-masked]>
Date: Thu, 15 Sep 2005 09:47:38 -0400

I actually think that getting into the potential failures is not 
worthwhile.  Brian's point is that periodically updating emergency call 
routing information at the far edge of the network is not as robust a 
design as letting the responsible party handle the routing.

This concept is familiar to Internet historians.  The most radical 
difference between the circuit-switched model and the Internet model is 
that the originating edge does not know how the (call) packet is being 
routed.  Routing takes place closer to the destination so that less 
routing information needs to be propagated through the network.  
Although Brian's point regards emergency-call routing rather than 
packet routing, the engineering principle is the same.

John

On Sep 15, 2005, at 9:09 AM, Andrew Newton wrote:
> Perhaps we should have a better understanding of what failures you are 
> trying to avoid.  After all, if infrastructure is failing then that 
> can mean much more than SIP proxies, it can mean copper and fibber 
> being cut and all manner of problems.  If infrastructure is failing, 
> it would seem that lower layer redundancies such as anycast might be 
> more effective.
>
> Before inflicting complexity on 99.99% of the cases for something that 
> is only needed 0.01% of the time, there should be a better

---

From: Andrew Newton <[email-masked]>
Date: Thu, 15 Sep 2005 15:22:22 -0400

On Sep 15, 2005, at 9:47 AM, John Schnizlein wrote:

> worthwhile.  Brian's point is that periodically updating emergency  
> call routing information at the far edge of the network is not as  
> robust a design as letting the responsible party handle the routing.

Conceptually, what is the difference between a list of end points  
delivered with a DHCP lease time and a list of end points delivered  
with DNS Time-To-Live?  Because MX records are used quite  
successfully near that same edge.

Anyway, your description of where to place this control still does  
not rule out anycast.

-andy

---

From: John Schnizlein <[email-masked]>
Date: Thu, 15 Sep 2005 17:22:10 -0400

On Sep 15, 2005, at 3:22 PM, Andrew Newton wrote:
> with DNS Time-To-Live?  Because MX records are used quite successfully 
> near that same edge.
>
> Anyway, your description of where to place this control still does not 
> rule out anycast.
>

The conceptual difference between DHCP and DNS is that DHCP is intended 
to provide a host with configuration options appropriate for its local 
network attachment; DNS is intended for hosts to look up records 
associated with host names that are (mostly) not local.  Careful design 
and redesign when initial problems (like the need for negative caching) 
were found has led to a global operation of DNS caching that has been 
proved to work. This good design allows each domain to update its own 
records, new domains to be found through referrals, and the load on 
servers to be workable.  Nobody has explained what protocol would 
provide for the distribution and selection of all those URIs that would 
have to be in all the DHCP servers that are not advertised to the 
outside world.

DHCP leases are entirely a local matter, the DNS TTL is set by the 
remote domain's administration and decremented throughout any caches.  
DHCP has no design for caching.

MX records are specific to email exchanges; SRV records generalize this 
mechanism rather than inventing a new resource record for every 
application.  MX records work because the SMTP hosts have names and 
addresses in the DNS - unlike arbitrary geographic or civic locations.  
It is unclear to me how DNS could be relevant here.

What proposal for routing emergency calls to or among PSAPs?

I have to admit I do not understand what problem we are solving here.  
To my way of thinking, a reasonable and simple approach is for hosts to 
include their locations (information local to the host) in an emergency 
call request, which goes to an emergency-call router (sip gateway for 
whatever number means emergency).  The emergency-call router would have 
emergency call routing information enabling it to forward the request 
to (toward) the relevant PSAP.  This information would at some point 
along its forwarding path use the call-originating host's location to 
forward the request.  Information would have to be shared only between 
relative neighbors in each aspect of the call handling.  Any of the 
components that were critical would have redundant operational peers.  
Why attempt propagation of information beyond where it is needed?

John

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Sep 2005 10:17:09 -0400

On Sep 15, 2005, at 5:22 PM, John Schnizlein wrote:

>> delivered with a DHCP lease time and a list of end points  
>> delivered with DNS Time-To-Live?  Because MX records are used  
>> quite successfully near that same edge.
>>
> The conceptual difference between DHCP and DNS is that DHCP is  
> intended to provide a host with configuration options appropriate  
> for its local network attachment; DNS is intended for hosts to look  
> up records associated with host names that are (mostly) not local.   
> Careful design and redesign when initial problems (like the need  
> for negative caching) were found has led to a global operation of  
> DNS caching that has been proved to work. This good design allows  
> each domain to update its own records, new domains to be found  
> through referrals, and the load on servers to be workable.  Nobody  
> has explained what protocol would provide for the distribution and  
> selection of all those URIs that would have to be in all the DHCP  
> servers that are not advertised to the outside world.
>
> remote domain's administration and decremented throughout any  
> caches.  DHCP has no design for caching.
>
> MX records are specific to email exchanges; SRV records generalize  
> this mechanism rather than inventing a new resource record for  
> every application.  MX records work because the SMTP hosts have  
> names and addresses in the DNS - unlike arbitrary geographic or  
> civic locations.  It is unclear to me how DNS could be relevant here.
>
> I have to admit I do not understand what problem we are solving  
> here.  To my way of thinking, a reasonable and simple approach is  
> for hosts to include their locations (information local to the  
> host) in an emergency call request, which goes to an emergency-call  
> router (sip gateway for whatever number means emergency).  The  
> emergency-call router would have emergency call routing information  
> enabling it to forward the request to (toward) the relevant PSAP.   
> This information would at some point along its forwarding path use  
> the call-originating host's location to forward the request.   
> Information would have to be shared only between relative neighbors  
> in each aspect of the call handling.  Any of the components that  
> were critical would have redundant operational peers.  Why attempt  
> propagation of information beyond where it is needed?

Perhaps we ought to go back to thrust of the objection that was  
raised: a device is given a 24 hour validity duration on a list of  
end points but there is an unforeseen reason for it to be updated 12  
hours after the device was given the information.  My question was  
simply, why is that duration unacceptable when it is a DHCP lease but  
acceptable when it is a DNS TTL?  Both will prevent the information  
from being updated before the end of the duration.

-andy

---

From: John Schnizlein <[email-masked]>
Date: Fri, 16 Sep 2005 10:47:16 -0400

As you know, the caching specification for DNS makes the TTL the upper 
bound on how long before the client gets a fresh value from an 
authoritative server.  The problem with using DHCP is not the duration 
of an address lease, but that there is no mechanism identified for 
getting new URIs into the DHCP servers.

Why is the comparison of DNS and DHCP relevant?  We have seen no 
argument that continuing the practice of PSAPs (which might be SIP 
proxies for VoIP) routing emergency calls among themselves based on 
location information in the call request.  The unnecessary 
"optimization" of getting better than default PSAPs into the calling 
host has unspecified needs for new protocols to distribute information 
that the PSAPs might not want to share as widely as proposed.

John

On Sep 16, 2005, at 10:17 AM, Andrew Newton wrote:
>> ...
> raised: a device is given a 24 hour validity duration on a list of end 
> points but there is an unforeseen reason for it to be updated 12 hours 
> after the device was given the information.  My question was simply, 
> why is that duration unacceptable when it is a DHCP lease but

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 16 Sep 2005 12:28:18 -0400

Andy,

> raised: a device is given a 24 hour validity duration on a 
> list of end points but there is an unforeseen reason for it 
> to be updated 12 hours after the device was given the 
> information.  My question was simply, why is that duration 
> unacceptable when it is a DHCP lease but acceptable when it 
> is a DNS TTL?  Both will prevent the information from being 
> updated before the end of the duration.
> 

Correct me if wrong....in practice, are not DNS TTLs normally much shorter
than DHCP lease times?

Of course, beyond the above philosophical argument, the PSAP has no control
over DHCP lease times, where in the proposed DNS solution, they have control
over TTLs.

-Marc-

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Sep 2005 14:13:26 -0400

On Sep 16, 2005, at 10:47 AM, John Schnizlein wrote:

> As you know, the caching specification for DNS makes the TTL the  
> upper bound on how long before the client gets a fresh value from  
> an authoritative server.

And a DHCP client can renew its lease before the lease time is up.   
What's your point?  Both are unreliable for the purposes of preemption.

>   The problem with using DHCP is not the duration of an address  
> lease, but that there is no mechanism identified for getting new  
> URIs into the DHCP servers.

Do DHCP servers have such quirky IP connectivity that they cannot use  
the same LCMS as a phone or gateway?

> "optimization" of getting better than default PSAPs into the  
> calling host has unspecified needs for new protocols to distribute  
> information that the PSAPs might not want to share as widely as  
> proposed.

The objection raised was not about call routing based on location,  
but was about call routing based on disaster recovery.
Again... Perhaps we ought to go back to thrust of the objection that  
was raised: a device is given a 24 hour validity duration on a list  
of end points but there is an unforeseen reason for it to be updated  
12 hours after the device was given the information.  My question was  
simply, why is that duration unacceptable when it is a DHCP lease but  
acceptable when it is a DNS TTL?  Both will prevent the information  
from being updated before the end of the duration.

I have no problem with calls being routed be proxies.  Actually, for  
the objection that was raised, that seems to be a pretty good place  
to do it.

> Correct me if wrong....in practice, are not DNS TTLs normally much  

TTLs where? in the roots? in TLDs? in SLDs?  From what Henning has  
said, for this particular case they would be set for a very, very  
long time.  I take that to mean months.

> over DHCP lease times, where in the proposed DNS solution, they  

True, but it doesn't disprove my point.

I also wonder, if DHCP lease times are so untrustworthy, then perhaps  
LCI should not be delivered via DHCP either.

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Fri, 16 Sep 2005 15:23:06 -0400

Andy,

> > Correct me if wrong....in practice, are not DNS TTLs normally much 
> > shorter than DHCP lease times?
> 
> TTLs where? in the roots? in TLDs? in SLDs?  From what 
> Henning has said, for this particular case they would be set 
> for a very, very long time.  I take that to mean months.

I can't comment on Henning's statement, I don't know the context.  But I
can't imagine whatever mechanism ends up being the solution to effect
emergency call routing changes, that most PSAPs will agree to 'months'.

My experience (admittedly not much) has been DHCP lease times in numbers of
days/weeks whereas DNS TTL in numbers of hours.  The main point is PSAPs
will know/control the TTL in the DNS solution, neither of which can ever
happen with dhcp servers that distribute the PSAP uri.  You are absolutely
correct, once the TTL is set and read, it can't be retracted until the
caching entity's timer expires, but the point, it's a known (by the PSAP)
parameter.  The requirement/use case is the ability to change the routing of
emergency calls adhoc, based on unknown/untimed events.  I believe we should
deliver this capability to the PSAP community, even if it has the baggage of
the known/controllable timing parameters.

> 
> > Of course, beyond the above philosophical argument, the PSAP has no 
> > control over DHCP lease times, where in the proposed DNS solution, 
> > they have control over TTLs.
> 
> I also wonder, if DHCP lease times are so untrustworthy, then 
> perhaps LCI should not be delivered via DHCP either.

I don't understand your tie between lease time and LCI in a wired
environment (the target of RFC3825 and the dhc civic draft)?  Are you
assuming a wired device can change location (unplug and reattach at another
network access point) without recontacting dhcp?  We normally consider
walking the distances allowed by your ethernet-to-wall-jack cord to be the
same location.

-Marc-

---

From: Andrew Newton <[email-masked]>
Date: Fri, 16 Sep 2005 15:59:05 -0400

On Sep 16, 2005, at 3:23 PM, Marc Linsner wrote:

> days/weeks whereas DNS TTL in numbers of hours.

Hours?  COM/NET is 2 days.  I normally use one week for my SLDs.

> The main point is PSAPs

> actually happens.  Often, what you thought would work, doesn't.

So the objection was about things that do not go according to plan.   
You are arguing that one method is better than the other.  I am  
arguing that when you look at the objection, there is no difference.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Sep 2005 11:59:56 -0400

I'm not sure a DNS-vs.-DHCP discussion is all that helpful. Since a lot 
of messages have gone back and forth, it would help me at least to 
summarize some of the points and see if we can at least agree on the facts.

# The system we're building has a number of translations between the 
"dial emergency number" and the final IP address of the phone of the 
PSAP call taker, including at least:

(1) Caller maps location and service desired to PSAP URL, possibly using 
the mapping URL conveyed in DHCP

(2) The PSAP URL needs to be resolved via a sequence of DNS translations 
(NAPTR, SRV, A), each of which has a TTL value, based on standard SIP 
procedures documented in RFC 3263.

(3) The DNS resolution points to one or more SIP proxies, which in turn 
route calls to the next step, either another SIP proxy closer to the 
call taker or the call taker. Repeat step (2) and (3) until the phone rings.

# If the PSAP URL(s) are included in the DHCP information, presumably 
the DHCP server performs step (1) above, for each attached device based 
on its location. The draft does not really say so, but I'm certainly 
hoping that this is not manually configured. Presumably, this would take 
place at the time the client asks for an address or does a DHCPINFORM.

Let's see if I got the picture right.

Henning

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Sep 2005 12:15:56 -0400

Continuing to see if we can get a common picture; sorry to belabor 
points that everyone knows.

# DNS seems to be run in two different "modes".

Mode 1 (predictable): The TTL value of the DNS record is long, typically 
a day for resource records close to the leaves of the tree and longer 
further up. If a change in assignment is anticipated (e.g., new server), 
the administrator lowers the TTL value. Due to caching, both old and new 
IP addresses, for example, need to continue to work during the period 
when some clients have old information and some get the new information.

If you want real failover, you need to list all possible servers in 
NAPTR and SRV records. This is essentially the approach recommended by 
SIP. It is not feasible for web applications since A records don't have 
the necessary properties and HTTP doesn't know about SRV.

Mode 2 (CDN mode): This mode is used by Akamai and other content 
distribution networks (CDNs). The TTL of records is set very low 
(seconds), with essentially no caching. Often, the answer returned by 
the DNS server varies by who is asking. This is used for round-robin DNS 
load balancing and use-nearest-server where the DNS server looks at the 
querying IP address of the resolver and picks a good answer.

If you want failover, the DNS server just returns another (live) server. 
However, this assumes that the DNS server knows which servers are 
reachable by the querier. If the network is hosed badly, just because 
the DNS server responsible for server A can talk to server A does not 
mean that the client can do likewise.

Thus, it is certainly possible to build a DNS-based failover system in 
Mode 2. Clearly, if a PSAP operates in Mode 1, with A records only, and 
then suddenly decides that it needs Mode 2, it's in trouble. However, 
firing its network admin would be one of the appropriate things to do in 
that case - it clearly didn't use the protocols in the right way. The 
important point to note is that the PSAP is in control, which includes 
the ability to shoot itself in the foot. I wouldn't necessarily 
recommend that PSAPs outsource their DNS operations to FEMA.

Henning

---

From: John Schnizlein <[email-masked]>
Date: Sun, 18 Sep 2005 14:41:17 -0400

Answers embedded in context:

On Sep 16, 2005, at 2:13 PM, Andrew Newton wrote:
>> upper bound on how long before the client gets a fresh value from an 
>> authoritative server.
>

The only point was trying to answer your question. Because the DNS 
protocol specifies that cached entries time out based on the TTL 
specified at the authoritative server, delays in getting authoritative 
responses are controlled at the source.  There is no such guarantee for 
the hypothetical distribution of PSAP information to DHCP servers.

How is "purposes of preemption" related to the discussion?

>> lease, but that there is no mechanism identified for getting new URIs 
>> into the DHCP servers.
>

Nobody (but you) said that DHCP servers have "quirky IP connectivity".  
  The DHCP server is what performs the protocol function.  As a 
practical matter, since the purpose of DHCP is entirely for 
configuration within an administration, there is no reason for the host 
on which the protocol server operates to be reachable from outside the 
perimeter of that organization.  Unlike DNS, DHCP is not designed to 
provide time-limited, cached-for-efficiency, global access to 
information. Nothing about this protocol function relates to getting 
information from outside the local administrative area.  If a protocol 
were proposed to add this capability to DHCP, it would deserve careful 
review.

>> Why is the comparison of DNS and DHCP relevant?

Please answer this question before continuing the thread.

>> We have seen no argument that continuing the practice of PSAPs (which 
>> might be SIP proxies for VoIP) routing emergency calls among 
>> themselves based on location information in the call request.  The 
>> unnecessary "optimization" of getting better than default PSAPs into 
>> the calling host has unspecified needs for new protocols to 
>> distribute information that the PSAPs might not want to share as 
>> widely as proposed.
>
> The objection raised was not about call routing based on location, but 
> was about call routing based on disaster recovery.

Where was this objection raised?

> was raised: a device is given a 24 hour validity duration on a list of 

I have not seen any claim (other than your strawman) that some delay 
'is unacceptable when it is a DHCP lease but acceptable when it is a 
DNS TTL".  Where did you find this claim?

The relevant comparison is between the subject proposal for 
distribution (through an undefined protocol with undefined delays 
between authoritative information and its use for emergency call 
routing) and the presumed alternative of PSAP location during the call 
setup.

> the objection that was raised, that seems to be a pretty good place to 
> do it.

Does this statement imply that you oppose the "optimization" proposed 
in the subject draft, since it is the source of the problem that raised 
the objection?

>> control over DHCP lease times,
>> where in the proposed DNS solution, they have control over TTLs.
>

What point is that?

> LCI should not be delivered via DHCP either.

I have not seen any claim that DHCP lease times are untrustworthy.  
Where was this claimed?

The point that has been made is that DHCP is useful for configuring 
hosts with local information (such as its location) within a local 
administration, but that it seems a poor choice for obtaining 
information that can be changed in a remote location under a different 
administration.  The principle is to use protocols for the sorts of 
things for which they were designed.

John

---

From: "Brian Rosen" <[email-masked]>
Date: Mon, 19 Sep 2005 09:54:43 -0400

I think that we should anticipate things going wrong in ways we don't
predict. 

For me, that means that we should NOT rely entirely on old (as in days)
mapping data.  We should, instead, attempt mapping at the time of the call,
and use that.  It just seems much more prudent to allow the mapping data to
change in time frames measured in hours if not minutes.

It may be that it fails, for lots of reasons, and thus we should have a
cached version of the mapping available.  

You can imagine circumstances where you have both a mapping change, and
there is overload (or loss of connectivity) to the mapping service.  While I
would like to engineer systems to reduce the probability, it can happen.
Those callers would be hosed.  The cached data would be wrong.  

No system is going to be perfect, or foolproof.  All we can do is boost the
odds.  I think presuming mapping data can change, and thus attempt mapping
at the time of the call, is one of the steps we can and should make to
improve the odds.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew Newton
Sent: Friday, September 16, 2005 3:59 PM
To: Marc Linsner
Cc: 'ECRIT'
Subject: Re: [Ecrit] draft-polk-dhc-uri-00

-andy

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Sep 2005 14:06:46 -0500

At 11:59 AM 9/17/2005 -0400, Henning Schulzrinne wrote:
>I'm not sure a DNS-vs.-DHCP discussion is all that helpful. Since a lot of 
>messages have gone back and forth, it would help me at least to summarize 
>some of the points and see if we can at least agree on the facts.
>
># The system we're building has a number of translations between the "dial 
>emergency number" and the final IP address of the phone of the PSAP call 
>taker, including at least:
>

DHCP can also - based on the ID - provide the ESRP URI - which is your #3 below

>route calls to the next step, either another SIP proxy closer to the call 
>taker or the call taker. Repeat step (2) and (3) until the phone rings.
>
># If the PSAP URL(s) are included in the DHCP information, presumably the 
>DHCP server performs step (1) above, for each attached device based on its 
>location. The draft does not really say so, but I'm certainly hoping that 
>this is not manually configured.

I didn't get into what was not a DHCP function in the ID, no. Just as 3825 
and your civic ID don't articulate how the DHCP server learns a client's 
location. In those cases, the DHCP server knows to pass along a circuitID 
to some external server, wait for an answer, then reply to the client with 
its location. The same assumptions are made in this ID. The bar shouldn't 
be raised now for this ID.  But perhaps I should make the same operational 
analogy as is present in 3825 and your civic ID.

>Presumably, this would take place at the time the client asks for an 
>address or does a DHCPINFORM.

yes, or I have it possible that the server sends this information 
unsolicited to the client, which can be ignored without causing error(s).

>Let's see if I got the picture right.

close

>Henning

cheers,
James

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Sep 2005 15:44:47 -0500

>>>   The problem with using DHCP is not the duration of an address lease, 
>>> but that there is no mechanism identified for getting new URIs into the 
>>> DHCP servers.
>>
>>Do DHCP servers have such quirky IP connectivity that they cannot use the 
>>same LCMS as a phone or gateway?
>
>  The DHCP server is what performs the protocol function.  As a practical 
> matter, since the purpose of DHCP is entirely for configuration within an 
> administration, there is no reason for the host on which the protocol 
> server operates to be reachable from outside the perimeter of that 
> organization.  Unlike DNS, DHCP is not designed to provide time-limited, 
> cached-for-efficiency, global access to information.

Why are you saying global here?

Just as the DHCP server communicates with a wiremap server in 3825, it can 
communuicate with a pre-call mapping server. What is different is where 
this mapping server is, and it might/likely is external to the DHCP 
organization.

>Nothing about this protocol function relates to getting information from 
>outside the local administrative area.  If a protocol were proposed to add

/add/interwork

>this capability to DHCP, it would deserve careful review.
>
>>I also wonder, if DHCP lease times are so untrustworthy, then perhaps LCI 
>>should not be delivered via DHCP either.
>
>The point that has been made is that DHCP is useful for configuring hosts 
>with local information (such as its location) within a local 
>administration, but that it seems a poor choice for obtaining information 
>that can be changed in a remote location under a different 
>administration.  The principle is to use protocols for the sorts of things 
>for which they were designed.
>
>John
>

cheers,
James

                                 *******************

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 20 Sep 2005 16:45:48 -0400

One of the issues with using DHCP to do the mapping function is that it's
not universally implemented.  That means you cannot use it for everything.
That means we need more than one protocol to get the PSAP URI.  Given the
experience we are having with getting location, where we have two protocols,
some folks are demanding a third, and every phone has to implement every
protocol, that I am opposed to a mechanism that cannot be reasonably be
deployed in every environment.  By that criteria, DHCP would not pass
muster, DNS would.  IRIS and LUMP would also.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
James M. Polk
Sent: Tuesday, September 20, 2005 3:07 PM
To: Henning Schulzrinne; 'ECRIT'
Subject: Re: [Ecrit] draft-polk-dhc-uri-00 (big picture)

>the mapping URL conveyed in DHCP

DHCP can also - based on the ID - provide the ESRP URI - which is your #3
below

close

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Sep 2005 16:12:10 -0500

Brian

You have talked about mapping being old or stale or there is an outage or 
overload for a while.

Give me an example URI of your PSAP.

If your phone uses that URI (however your phone got it) to contact your 
PSAP, where will that INVITE go?

SIP will route it to your PSAP, right?

If that URI is old, is that PSAP not still yours?

If that URI is stale, is that PSAP not still yours?

If that URI is to a PSAP that is out of service, will not the proper SIP 
routing of the INVITE send it to an alternate PSAP?

If that URI is to an overloaded PSAP, is that not a general SIP problem, 
and probably a subject to having SIP routing take care of it and send the 
INVITE to that alternate PSAP?

We haven't addressed the reception of an INVITE by the wrong PSAP yet, and 
I feel we need to do this as well. What happens if this occurs and your 
INVITE goes to Philly? Shouldn't they have a Proxy (however stateful) that 
inspects your INVITE to ansure the location in the message is for the 
Philly PSAP jurisdiction?

And if it is not, to either reroute the INVITE to your PSAP, or to answer 
the call and ask where you are and then to a call transfer of some form?

cheers,
James

                                 *******************

---

From: John Schnizlein <[email-masked]>
Date: Tue, 20 Sep 2005 17:22:39 -0400

On Sep 20, 2005, at 4:44 PM, James M. Polk wrote:
>>   As a practical matter, since the purpose of DHCP is entirely for 
>> configuration within an administration, there is no reason for the 
>> host on which the protocol server operates to be reachable from 
>> outside the perimeter of that organization.  Unlike DNS, DHCP is not 
>> designed to provide time-limited, cached-for-efficiency, global 
>> access to information.
>

Because DNS was designed for and operates as a global lookup service 
for information maintained by individual authorities.

> Just as the DHCP server communicates with a wiremap server in 3825, it 
> can communuicate with a pre-call mapping server. What is different is 
> where this mapping server is, and it might/likely is external to the 
> DHCP organization.

There is a big difference between a local translation from wiremap and 
circuit-ID to location and the proposed service that maintains local 
and sufficiently current PSAP mappings that are administered elsewhere. 
  Since DHCP operation is clearly intended to be internal, it is 
stretching credulity to expect the DHCP operator to rely on external 
services in the process of allocating a local address.

>
>> Nothing about this protocol function relates to getting information 
>> from outside the local administrative area.  If a protocol were 
>> proposed to add
>
> /add/interwork

Whatever word you use, there is a huge semantic clash between local 
(DHCP) function and obtaining and maintaining the proposed remote 
information.

>> information that can be changed in a remote location under a 
>> different administration.  The principle is to use protocols for the 
>> sorts of things for which they were designed.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Sep 2005 16:35:37 -0500

At 04:45 PM 9/20/2005 -0400, Brian Rosen wrote:
>not universally implemented.

it's also not expected to be a one-size-fits-all solution... come on now.

>That means you cannot use it for everything.

SIP won't be used for everything so it shouldn't be considered either, by 
that same logic.

>That means we need more than one protocol to get the PSAP URI.

Doesn't the ECRIT Arch Considerations ID state exactly that?

>Given the

DHCP and what?

>deployed in every environment.

well that gets rid of SIP too... cuz some folks will implement H.323 or 
.248 and translate at their boundaries. Then there are the Cisco Skinny 
folks, and the MGCP folks...

>By that criteria, DHCP would not pass

Is DNS is in my phone?

IRIS is not on my phone.

LUMP is not on my phone.

SIP is.

Why don't we use SIP then for the layer 7 solution if you want ONE protocol 
under your assumption that SIP will be the signaling protocol? It is the 
ONE common protocol to everything you're working on. We've shown/state HTTP 
is not uniform or ubiquitous - so it's out. LUMP means SOAP, and I don't 
believe that's absolutely everywhere. What are you left with?

Why are you being so absolute?

IP is built on layers.

There should be one solution per (applicable) layer as a mandatory to 
implement.

By your same argument, location-by-reference AND location-by-value 
shouldn't be used either, because neither will be everywhere, and neither 
will be in the 3G and beyond phone.

cheers,
James

                                 *******************

---

From: Brian Rosen <[email-masked]>
Date: Tue, 20 Sep 2005 18:09:09 -0400

If we select my dns proposal, or lump or iris, every routing element can 
implement it, without exception.  If we use dhcp, only environments that 
support dhcp can use it.

The other location protocol is lldp-med, and the proposed third is 
HELD.

We certainly can have exactly one mapping protocol, and I think we 
should.  It does not bother me that phones don't do iris or lump, and 
even if they have ds support, they don't ecrit mapping.  Its new code.  
The difference is that dhcp requires local support, and that's not 
available everywhere. Dns and lump and iris don't need local support.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 20 Sep 2005 23:54:16 -0500

At 05:22 PM 9/20/2005 -0400, John Schnizlein wrote:
>>>Unlike DNS, DHCP is not designed to provide time-limited, 
>Because DNS was designed for and operates as a global lookup service for 
>information maintained by individual authorities.

Fair, but I read your comment like you thought I was expecting DHCP to be 
global in nature for this to work, and I do not have that expectation.

>>where this mapping server is, and it might/likely is external to the DHCP 
>>organization.
>
>circuit-ID to location and the proposed service that maintains local and 
>sufficiently current PSAP mappings that are administered elsewhere.  Since 
>DHCP operation is clearly intended to be internal, it is stretching 
>credulity to expect the DHCP operator to rely on external services in the 
>process of allocating a local address.

You have a problem with a, perhaps, once-every-24-hours download from a 
secure site that is outside the local domain?

>Whatever word you use, there is a huge semantic clash between local (DHCP) 
>function and obtaining and maintaining the proposed remote information.
>
>>>...

cheers,
James

                                 *******************

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Sep 2005 00:24:58 -0500

DNS, IRIS and LUMP are useless without location of the UA. Location seems 
to be coming from DHCP. In that *very*same* DHCP response IP packet can be 
the PSAP URI. that seems pretty efficient to me.  The lease mechanism can 
be used to provide a fairly fresh URI in the phones. SIP Routing can take 
care of reroutes due to:
         1- time of day routing changes
         2- overloads (by pushing the overload state to the Proxies)
         3- jurisdictional changes
         4- etc...
and
Call transfer:
         - whether before the operator answers the call
                 - because the local PSAP Proxy recognized the
                 INVITE from intended for another PSAP, or
         - when the operator asks the user where they are

will handle the rest of the cases.

We already need the call transfer procedure in place for VPNs.

For i3, the PSAP will have an ESRP for message inspection. This can do the 
message rerouting if necessary, and the PSAP administrators can control 
when that occus for the above 3 listed reasons (plus a few others)

At 06:09 PM 9/20/2005 -0400, Brian Rosen wrote:
>The other location protocol is lldp-med, and the proposed third is HELD.
>
>should.  It does not bother me that phones don't do iris or lump, and even 
>if they have ds support, they don't ecrit mapping.  Its new code.

cheers,
James

                                 *******************

---

From: John Schnizlein <[email-masked]>
Date: Wed, 21 Sep 2005 06:56:39 -0400

The fundamental problem is that the organizational and technical 
details of this "download from a secure site" must be specified and 
reviewed because there is widespread doubt that it is feasible.  For 
example, it appears that the site from which the download is performed, 
and the particular values downloaded should be different for different 
DHCP servers.

Expecting that enough DHCP-server operators would add this coordination 
burden to their internal services to justify any clients trying to use 
it seems to be unrealistic.  As Barbara asks: would you expect the DHCP 
server in her home router to perform this "download"?

John

On Sep 21, 2005, at 12:54 AM, James M. Polk wrote:
>
>>> Just as the DHCP server communicates with a wiremap server in 3825, 
>>> it can communuicate with a pre-call mapping server. What is 
>>> different is where this mapping server is, and it might/likely is 
>>> external to the DHCP organization.
>>
>> There is a big difference between a local translation from wiremap 
>> and circuit-ID to location and the proposed service that maintains 
>> local and sufficiently current PSAP mappings that are administered 
>> elsewhere.  Since DHCP operation is clearly intended to be internal, 
>> it is stretching credulity to expect the DHCP operator to rely on 
>> external services in the process of allocating a local address.
>
> You have a problem with a, perhaps, once-every-24-hours download from 
> a secure site that is outside the local domain?
>

---

From: Andrew Newton <[email-masked]>
Date: Wed, 21 Sep 2005 08:26:21 -0400

On Sep 21, 2005, at 6:56 AM, John Schnizlein wrote:

> reviewed because there is widespread doubt that it is feasible.

It just hasn't been specified.  Calling it a "fundamental problem"  
seems premature.

> For example, it appears that the site from which the download is  
> performed, and the particular values downloaded should be different  
> for different DHCP servers.

Isn't this the same problem we have with LCMS?

> Expecting that enough DHCP-server operators would add this  
> coordination burden to their internal services to justify any  
> clients trying to use it seems to be unrealistic.  As Barbara asks:  
> would you expect the DHCP server in her home router to perform this  
> "download"?

Well, that certainly is an interesting question.  Just as interesting  
as: would you expect the DHCP server in her home router to have been  
given its civic address?  If we cannot expect users to enter in a URI  
for the download, we certainly cannot expect users to enter in their  
multiline civic address.  Especially when it must be done carefully,  
as was the conclusion here: http://www1.ietf.org/mail-archive/web/ 
ecrit/current/msg00746.html ... and especially given that this type  
of thing may not work with the Pizza Hut delivery mapping server.

> muster, DNS would.  IRIS and LUMP would also.

There are two things being said here:

1) DHCP is not universally implemented.
   and
2) DHCP is not a good LCMS

I agree.  From what I have read, I think James Polk would agree.

On point 1, not only is DHCP not universally implemented, neither is  
any type of network-based location sighting.  Therefore, I do not  
think it is unreasonable for James to suggest tweaks to protocols  
that have not been deployed (and in some cases, are not even ratified  
as standards).

Also, I do not think James is saying that DHCP is the only way this  
can be done.  I think his intention is that if DHCP is being used for  
LCI, then it can also be used for URIs.  If other methods can be used  
for LCI, then they can also be used for URIs.

On point 2, James is not proposing another LCMS.  If anything, he is  
proposing it take place at another stage.  And even then, not even in  
all cases: LCMS will likely be needed just before call setup in most  
geo cases.

Additionally, there is one other use for his proposal.  If LCMS is  
not available at call setup, then this is a good way of provisioning  
default/backup PSAP URIs (given all the talk about the need for  
anticipating what we cannot anticipate).

-andy

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 21 Sep 2005 09:48:25 -0400

> secure site that is outside the local domain?

Why 'once-every-24-hours'?  Where did number this come from?  How do you
propose to 'enforce' this?

-Marc-

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Sep 2005 16:52:36 -0500

At 09:48 AM 9/21/2005 -0400, Marc Linsner wrote:
>Why 'once-every-24-hours'?  Where did number this come from?

hmmm.... isn't this the number that's currently available today for 
emergency calling changes?

>How do you

"enforce" and "the IETF" don't mix.

We don't write laws...

cheers,
James

                                 *******************

---

From: "Marc Linsner" <[email-masked]>
Date: Thu, 22 Sep 2005 09:49:09 -0400

> > > You have a problem with a, perhaps, once-every-24-hours download 
> > > from a secure site that is outside the local domain?
> >
> hmmm.... isn't this the number that's currently available 
> today for emergency calling changes?

No.

> "enforce" and "the IETF" don't mix.

OK, let's dance.  How do you precieve a PSAP (routing db authority)
effecting a routing change that is cached for an unknown amount of time in
an unknown group of dhcp servers?

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 22 Sep 2005 18:15:56 -0400

This draft provides a mechanism to return URIs from DHCP.  Here in ecrit,
one we would have interest in is the PSAP URI(s).  

James proposes that we support the notion of a PSAP URI being returned from
DHCP.  

There has been a lot of discussion on this one on the list.  Before we go
any farther, would it be appropriate to ask who else on this list thinks
this is a good idea?  If there is a lot of support, then we can get into
details.  If there isn't a lot of support, then we don't have to spend time
on it.

Please note that, as I understand it, James is NOT proposing that DHCP be
considered a candidate for the protocol to perform the mapping between
location and the URI of a PSAP.  He is proposing that DHCP be one of several
mechanisms that could be used to tell an endpoint what the result of mapping
would be.  I'm guessing that the DHCP server (or something connected to it)
would use the mapping protocol to map location to PSAP URI, and deliver the
result to the endpoint.

My personal opinion is that this is not a good idea, that we don't want
another mechanism between the mapping protocol and the end device, and that
DHCP is not an appropriate protocol to deliver the URI of the PSAP.  Among
other reasons, unless we mandated that DHCP is the only way an endpoint
finds out the URI of a PSAP, then every endpoint that looked for this DHCP
option would have to implement at least one other way to get it.  To me,
that makes this idea pretty worthless.

Brian

---

From: Ted Hardie <[email-masked]>
Date: Thu, 22 Sep 2005 17:04:53 -0700

>details.  If there isn't a lot of support, then we don't have to spend time

I support getting down to the details; I may or may not support what
emerges once we get there.  I have some concerns about how to handle
what schemes are allowed, as there are tradeoffs here in interoperability
that may be tricky.  But I wouldn't rule the discussion out; it's a useful
tool in a toolkit.

For what it's worth, I'm in the camp that believes we will never reach 100%
reliability with any single solution, and I question whether we'll get
to five nines.  I believe the most robust situation is one in which
we understand multiple mechanisms as layered defenses against
the inability to make this call.

Let's say I have a dhcp capable device, which has a mapping protocol client and
a sip client, and talks to a sip proxy that is also capable of mapping.  My ideal
is that at emergency time the client takes the location, maps to the correct PSAP,
initiates the call and sends the location along with as useful data for the PSAP. 
But I would have the client request the location mapping at boot and
periodically thereafter, so that stale data is available if fresh  is not.  And if the
DHCP server provided information, it would get used until fresher data
replaced it (imagine turning on your sip phone to report the emergency)

And if none of the above were available, I would initiate a sip
call to an "sos" uri sending the location information I had so it could
do the mapping if it is capable of doing so; if I had no location information, I
would still send to the "sos" URI, and hope either the proxy could determine
my location (as it could in some networks) or it was willing to default route
me so a human could ask.

Put all of the above together, and I'll get closer to five nines than using any one
of them.  And I think the principle by which data inconsistency is resolved may
be simpler than some people wins.  In many, many cases "freshest data wins"
is good enough.
			regards,
				Ted Hardie

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Sep 2005 20:35:53 -0400

Learning the location of mapping servers seems well within the overall 
scope of ECRIT. However, depending on the architecture, DHCP may or may 
not be the right approach for that and it will probably be hard to tell 
until the mapping mechanisms have gelled a bit more.

Thus, I'm not convinced that the DHCP mechanism proposed currently 
addresses any ECRIT charter items, unless this is indeed proposed as a 
mapping protocol.

For the reasons others and I stated earlier, I have serious concerns 
about the protocol as a mechanism to learn PSAP identities:

- serious security vulnerabilities that a non-deployed shared-key 
algorithm does not address and that differ significantly from other uses 
of DHCP;

- undefined caching and lifetime definitions that make it hard to 
predict what kind of information end systems will be getting when and 
when stale information will be "flushed" from the system;

- additional implementation and method-selection effort;

- if systems attempt to use both a mapping protocol and DHCP, the 
complexity of dealing with conflicts;

- the difficulty of supporting additional PSAP URIs for service-specific 
  URIs (mountain rescue, etc.), with another namespace to manage;

- the lack of generality that makes it difficult to apply this mapping 
mechanism to other location-to-URI problems.

I suspect that some of these issues can be addressed by clarifying the 
description, but some of the issues seem fundamental in having a second 
approach.

We already have a mechanism to have end systems delegate resolution to 
third parties, namely by having the outbound proxy perform the mapping.

As a procedural matter, I don't think it is incumbent upon the working 
group to demonstrate that a protocol does not work or does not work well 
in its current form, but rather for the authors to demonstrate that the 
proposal addresses agreed-upon requirements.

Henning

---

From: Ted Hardie <[email-masked]>
Date: Thu, 22 Sep 2005 17:54:22 -0700

At 8:35 PM -0400 9/22/05, Henning Schulzrinne wrote:
>For the reasons others and I stated earlier, I have serious concerns about the protocol as a mechanism to learn PSAP identities:

>- serious security vulnerabilities that a non-deployed shared-key algorithm does not address and that differ significantly from other uses of DHCP;
>
>- undefined caching and lifetime definitions that make it hard to predict what kind of information end systems will be getting when and when stale information will be "flushed" from the system;

This is why I believe we need to drill down to details.  If, for example, the system
told you what the local tel: URI was for emergency calls (tel:911, tel:999, tel:112,
etc.), there is some marginal utility there and the likelihood of the information being
stale without a location change is nil.  For some constructions of psap URIs, the same
might be true; for others they are not.  It depends on the scheme, the deployment
scenario, etc.

None of this changes the basic principle that having some data is having no data.
As long as fresher data/data derived from a mapping protocol is known to
kick this out, then I think we're still better off.  The "complexity" of reconciling
is still up to us to specify, and I think with some models we can do well here.

But without the discussing the details, we don't know how well the tool fits.
The URIs carried in DHCP mechanism is very, very general.  Unless the mechanism
used here gets specified in more detail, the question of suitability will always
get answered "it depends".

My personal take and 2 cents,
			regards,
				Ted Hardie

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 22 Sep 2005 21:14:53 -0400

> etc.), there is some marginal utility there and the likelihood of the information being

This idea has popped up in the past and isn't really related to the DHCP 
discussion, but...

I don't think this is a workable idea. The DHCP server has no idea what 
proxy server is going to resolve tel URIs for me. If I use sipgate.de as 
my VSP and my Verizon DHCP server tells me to use tel:911, I suspect 
that this is not going to work very well when my SIP request hits the 
proxy somewhere in Munich.

If the proxy server is specified somehow and known to be local to the 
caller, there is no advantage here - the end system might as well just 
have the proxy server resolve the SIP request, marked as an emergency 
call, to the appropriate number or SIP URI.

Henning

---

From: Andrew Newton <[email-masked]>
Date: Thu, 22 Sep 2005 21:49:46 -0400

> that makes this idea pretty worthless.

Why is it that the lack of DHCPs ubiquity is acceptable for the  
sighting of location information, which is key to the success of the  
LCMS, but this same protocol must be ubiquitous in order for it to be  
used for an optional optimization?

As for there being multiple methods to obtain this information, that  
is already the case today with location information.  Why is this not  
a problem, especially given that location information is essential to  
the entire premise of this working groups output?

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 23 Sep 2005 08:25:38 -0400

I deeply deplore the location determination situation we find ourselves in.
It is my opinion that the IETF (I suspect that means geopriv) should state
that the only acceptable protocol for getting location into the endpoint is
DHCP, and if you manually provision an IP address you could either use DHCP
for location anyway or manually provision location.  DHCP will work in every
circumstance.

LLDP-MED, in my opinion, is 100% duplicative, and should not be deployed.
It changes the element that reports location to be one which is closer to
the endpoint.  While that is a positive thing, the negatives of two options
outweigh the positive.  LLDP-MED is only really suitable for deployment in
enterprise situations where managed Ethernet switches face the endpoints,
but manufactures of endpoints don't know if they will be used in a home or
an enterprise.  

DHCP is suitable in every environment for endpoints.  Home routers may need
some protocol to get location that isn't DHCP so they can give location to
endpoints via DHCP, but we don't have to implement that in every endpoint.

In my opinion, HELD is a very large mistake being pushed for a poor reason:
the installed base of home routers for which in the field upgrade of
firmware is deemed to be so difficult that the promoters of L7 protocols
believe every phone from now till the next big thing should need a third
protocol.  That is, again in my opinion, erroneous, and we should decline to
standardize an L7 location determination protocol.

I have no illusions that my opinions as expressed above are prevalent enough
that we will in fact do what I suggest.  I'm advising endpoint manufacturers
that all phones will need to implement all three protocols.  That is stupid,
but it's reality.  I've probably committed an error raising these issues on
this thread in this venue as we should argue the above in geopriv, but I've
said this before, and we're still spending lots of time on them so rough
consensus is not going my way :(

However to repeat this mistake in the mapping side is wrong.  All of the
proposed protocols for mapping are simple enough that endpoints can
implement them directly.  We'll choose one, and that's it, we don't need
anything else. Having other options forces all endpoints into more code, for
no good reason.

Having one protocol makes life simpler for everyone.  With this particular
one (DHCP for mapping determination), endpoints have to implement the
mapping protocol directly, and having done so, should choose to use it,
because the DHCP mechanism is another intermediary that would have to
implement the mapping protocol, and it can fail.  It adds no value; the
endpoint can duplicate the function itself, and in fact, since it doesn't
know if the DHCP option will be available, HAS to duplicate the
functionality.  

If this was proposed as the ONLY mechanism, then I'd have fewer problems.
In fact if DHCP was the only location determination mechanism, and this was
the only mapping determination protocol, then I would be fairly happy.
Folks, you CAN query DHCP at call time.  You can query DHCP any time.  DHCP
is fast.  I'm not worried about DHCP as a protocol; I just don't want any
options where we don't need any, because of the effect on hundreds or
thousands of endpoint designs.  I'm a little more worried about robustness,
we don't design DHCP servers to be ultra reliable.  However, I suspect if
your DHCP server is down, you can't do much of anything anyway, and the
cached value is likely to be good anyways even if I don't want to rely on
it.

Brian

-----Original Message-----
From: Andrew Newton [mailto:[email-masked]] 
Sent: Thursday, September 22, 2005 9:50 PM
To: [email-masked]
Cc: 'James M. Polk'; 'ECRIT'
Subject: Re: [Ecrit] draft-polk-dhc-uri-00

-andy

---

From: John Schnizlein <[email-masked]>
Date: Fri, 23 Sep 2005 09:58:10 -0400

Brian,

I suspect that you have misinterpreted the extended discussion 
exploring alternatives as diverging opinions.  I mostly agree with what 
you say here - minor clarifying comments embedded in context.  It is 
possible that we already have "rough" consensus on the set of 
conclusions you collected here.  There are, of course, particular 
advocates of other views, but I have seen no coherent alternative 
collection.

> for location anyway or manually provision location.  DHCP will work in 

The above conclusion is for the case where the host gets its location 
from the network.  There is no prohibition on the likely case where 
(especially mobile) hosts know their location by other means such as 
GPS or Galileo.

> endpoints via DHCP, but we don't have to implement that in every 

This is compatible with PPPoE and PPPoATM which uses PPP rather than 
DHCP to assign attributes to the router.  There is no reason that the 
Network Control Protocol (NCP) [RFC 1332] could not include a 
configuration option analogous to the option in RFC 3825 along with the 
IP address of the host (DSL router).  The router can provide this 
location to the host using the dynamic host configuration protocol.

> standardize an L7 location determination protocol.

Since the deployment of Internet telephony is in its infancy now, the 
majority of IP phones that will need the ability to provide their 
locations to emergency services are not deployed.  The currently 
installed base is a tiny fraction of what is expected at general 
deployment, and should not interfere with designing the general 
solution around Internet standard protocols as much as possible.

> cached value is likely to be good anyways even if I don't want to rely 

Well put.  DHCP is not the problem.  The problem with the subject 
proposal is inserting DHCP unnecessarily in the process.  It is 
unhelpful to have hosts get information through DHCP that they can get 
as well or better otherwise because that information is not part of the 
local network environment.

John

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 23 Sep 2005 12:22:33 -0400

Agree in all respects.

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]] 
Sent: Friday, September 23, 2005 9:58 AM
To: [email-masked]
Cc: 'Andrew Newton'; 'ECRIT'
Subject: Re: [Ecrit] draft-polk-dhc-uri-00

Brian,

John