RE: [Geopriv] RE: [dhcwg] Re: I-D ACTION:draft-ietf-geopriv-dhcp-civil-07.txt

Hmm.. Sounds like OBO to me. ;)

I actually think that network management find this misbehaving phone has
other better options at hand than this. If the server doesn't support
LCI then I don't think that this option is going to help, and if the
server does support LCI then other options such using the lease query
mechanism proposed in
http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-09.txt to
get the LCI data or relay data from the server directly.

I still think that the potential long term mess is far worse than the
short-term gains.

Cheers
James

> -----Original Message-----
> From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
> Sent: Tuesday, 22 November 2005 10:03 AM
> To: Winterbottom, James
> Cc: Randall Gellens; geopriv@ietf.org; DHCP discussion list
> Subject: Re: [Geopriv] RE: [dhcwg] Re: I-D
ACTION:draft-ietf-geopriv-dhcp-
> civil-07.txt
> 
> 
> 
> Winterbottom, James wrote:
> >>This does mean that a client has to make a possibly unpleasant
choice
> >>between not sending the information, and thus possibly making it
> >>harder be located in an emergency or possibly having poorer service
> >>in some other area, and sending it with no redistribution/retention
> >>limits.
> >
> >
> > [AJW] I simply don't understand this statement. If the end-point has
its
> > location, how is providing that location to a DHCP server going to
> > assist with emergency call routing?
> 
> It's a bit of a stretch, but the logic would be something like:
> 
> - End point knows location, but client application doesn't know how to
> retrieve or use it (this would include all current IP telephony soft
> clients, for example);
> 
> - in an enterprise environment, the proxy server gets to ask the DHCP
> server for location information (and uses it for emergency call
routing).
> 
> I agree that this is not a deployment scenario we should make the
> preferred outcome.
> 
> The more likely case is that this is used for network management
("find
> the misbehaving PC or phone").
> 
> 
> >
> > My personal opinion is that allowing the transfer of location from
the
> > client to the server in this manner is a significant stretch of the
> > intentions laid out in RFC-3694 and quite far reaching application
and
> > security implications.
> >
> >
> > Cheers
> > James
> >
> >
------------------------------------------------------------------------
> ------------------------
> > This message is for the designated recipient only and may
> > contain privileged, proprietary, or otherwise private information.
> > If you have received it in error, please notify the sender
> > immediately and delete the original.  Any unauthorized use of
> > this email is prohibited.
> >
------------------------------------------------------------------------
> ------------------------
> > [mf2]
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg