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

From: "Stark, Barbara" <[email-masked]>
Date: Tue, 20 Sep 2005 17:04:13 -0500

I have a few questions on all this.
Am I reading all of this correctly that there's a suggestion that VoIP
clients should use DHCP to get the uri of its PSAP provider?
My VoIP clients in my home talk to a DHCP server that resides in my home
router.
My home router doesn't talk to any DHCP server at all (it uses IPCP to
get configuration info).
Are proponents of a DHCP solution suggesting that my service provider
must implement a DHCP server? Would this DHCP mean that PPPoE must not
be used, or could it be some sort of DHCP that comes after PPPoE? And
are proponents suggesting that I not only must make sure my VoIP devices
support this functionality (which would be ok), but that my home router
has to either be upgraded or replaced? In my experience, end users will
resist all change to home routers unless they have no option (i.e.,
things break). End users will resist replacing home networks, unless
we're able to make things break if they don't. Should we require that a
VoIP device not work if it can't get a uri via DHCP (from the home
router)? That's the only thing that I can think of that's painful enough
to force someone to replace their home network.

What if my VoIP device is configured with a static IP address (static
netmask, gateway, and DNS, too) and isn't set to do DHCP? Is there still
some DHCP message that's proposed for it to use?
Barbara

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
John Schnizlein
Sent: Tuesday, September 20, 2005 5:23 PM
To: James M. Polk
Cc: ECRIT
Subject: Re: [Ecrit] draft-polk-dhc-uri-00

Answers embedded in context:

On Sep 20, 2005, at 4:44 PM, James M. Polk wrote:
>
>>>>   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.
>>>
>>> ...
>>   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?

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.

>> ...
>> 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.

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

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 163

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

---

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

>clients should use DHCP to get the uri of its PSAP provider?

The DHCP client in infrastructures it is condusive towards, yes

>My home router doesn't talk to any DHCP server at all (it uses IPCP to

This doesn't prevent your DSL modem from having this information through 
other means. This ID makes not assumptions about a multi-hop scenario like 
you have.

>must implement a DHCP server?

no, in your situation, it would be from your DSL modem to any client on 
your home network.

>Would this DHCP mean that PPPoE must not
>be used, or could it be some sort of DHCP that comes after PPPoE?

These are independent as far as I can tell

>And
>has to either be upgraded or replaced?

As with any extension not supported by a device, yes.

>In my experience, end users will
>things break).

Recent replacement marketing campaigns seem to be working to the contrary 
of this statement, at least where I live.

>End users will resist replacing home networks, unless
>we're able to make things break if they don't.

people in general are motivated for a few reasons, they have to gain 
something, or choose not to loose something.

Gaining the ability to call for local emergency help might be enough of a 
gain for people to make the change.

>Should we require that a
>router)?

There will have to be a default route of some sort.

Remember, your home DSL modem doesn't likely support RFC 3825 or the Civic 
ID yet, and that is a basis for this WG's effort too.

>That's the only thing that I can think of that's painful enough

If everything you have is static, then your PSAP URI might be too. This 
means you might have to rely on "the SIP Network" to route you sos@ INVITE 
to the right PSAP if it is not the one at your URI. This is not hard. A 
front-ending VSP should have this capability from the beginning of their 
operation.

An alternative to the static URI is to have a higher layer do the URI 
mapping before any emergency call. The Emergency Architecture 
Considerations ID states this as a layered approach.  I have a separate ID 
using SIP to do this coming soon.

The grand picture there would be if DHCP provides this PSAP (and other) 
URIs, great. If DHCP does not, for whatever reason, the UA knows this and 
requests the URIs using SIP. Why SIP? I believe it will be the one 
application layer protocol in the most endpoints - and this extension will 
not require significant changes to accomodate this request for the URIs.

>The information transmitted is intended only for the person or entity to 
>which it is addressed and may contain confidential, proprietary, and/or 
>privileged material. Any review, retransmission, dissemination or other 
>use of, or taking of any action in reliance upon this information by 
>persons or entities other than the intended recipient is prohibited. If 
>you received this in error, please contact the sender and delete the 
>material from all computers. 163

cheers,
James

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