At 02:42 PM 6/24/2009, Gabor.Bajko@nokia.com wrote:
>Below inline:
>
> >-----Original Message-----
> >From: ext James M. Polk [mailto:jmpolk@cisco.com]
> >Sent: Wednesday, June 24, 2009 11:08 AM
> >To: Bajko Gabor (Nokia-CIC/MtView);
> >bernard_aboba@hotmail.com; martin.thomson@andrew.com;
> >drage@alcatel-lucent.com; rbarnes@bbn.com; mlinsner@cisco.com
> >Cc: geopriv@ietf.org
> >Subject: RE: [Geopriv] Issue: version "negotiation"
> >
> >At 09:53 PM 6/23/2009, Gabor.Bajko@nokia.com wrote:
> >
> >> >>Some questions:
> >> >>
> >> >>a. Should a client implementation of RFC 3825bis be capable
> >> >of handling
> >> >>both v0 and v1 packets sent by a server?
> >> >
> >> >yes - because the server the client receives can be either
> >> >from a v0 or v1 server.
> >>
> >>It may, but it should not be required to. If the client
> >does not like
> >>the location version provided by the server, it may ignore it
> >
> >if this happens, then a client doesn't have location from
> >the server, and has NO MEANS to tell the server it doesn't
> >have location except to ask for Option 123 again, which will
> >result in the server sending the same v1 again - which the
> >client will reject.
> >
> >Is this a solution?
>
>The client can make use of multiple protocols to acquire its location.
this really isn't an answer, given that this discussion is all about
that to put into 3825bis -- a DHCP document.
>If it chooses to use DHCP, but does not like the encoding of the
>location it receives, it can choose to use some other protocol, like
>HELD or SUPL, to get its location (possibly from a different LIS) in
>a format it likes.
if a client uses HELD, why waste time with DHCP?
(I'm waiting for James and Martin to fall over.... ah, there they go)
I'll continue -- this isn't a catch all architecture discussion, this
is how to make DHCP work, and DHCP only work.
> >I believe you are suggesting a configuration, not a protocol design.
> >
> >>and try to find another server which provides the location with the
> >>desired version.
> >
> >but how *in DHCP*
> >#1 does a client learn which servers?
> >#2 does a client contact another server, given that it
> >received the DHCP OFFER from the client sending out a
> >broadcast message (asking for any server to answer)?
> >
> >This is one of the shortfalls of DHCP, the client accepts
> >the first answer from its broadcast, and doesn't move to the
> >next OFFER (if there even is one).
>
>Yes, it is difficult (if not impossible) in a DHCP-only LCP
>environment. But since LIS/LCP is a competivite market,
again - you are talking as if 3825bis needs to account for all these
other LCPs... it doesn't. This document is how DHCP works -- and the
WG was apparently unsatisfied with RFC 3825, so we are now modifying
it to make is a viable solution. We can't say 'oh, gee... use another
LCP if you want *that*...'. We need to define how *that* works in
DHCP the best way it can.
>if they want the location they provide to be used by clients, they
>better provide the location in a format in which clients expect it.
but your first reaction was to simply have the client ignore the
OFFER, which isn't a solution at all.
>- Gabor
> >>
> >> >-----Original Message-----
> >> >From: geopriv-bounces@ietf.org
> >> >[mailto:geopriv-bounces@ietf.org] On Behalf Of ext James M. Polk
> >> >Sent: Tuesday, June 23, 2009 12:23 AM
> >> >To: Bernard Aboba; martin.thomson@andrew.com;
> >> >drage@alcatel-lucent.com; rbarnes@bbn.com; mlinsner@cisco.com
> >> >Cc: geopriv@ietf.org
> >> >Subject: Re: [Geopriv] Issue: version "negotiation"
> >> >
> >> >At 02:07 AM 6/23/2009, Bernard Aboba wrote:
> >> >>Martin said:
> >> >>
> >> >>"Certainly we shouldn't be encouraging people to try to
> >> >send the old
> >> >>encoding".
> >> >>
> >> >>There are a number of potential cases here:
> >> >>
> >> >>a. Legacy (v0) client speaking to v1 server.
> >> >>b. Legacy (v0) client speaking to v0 server.
> >> >>c. V1 client speaking to v0 server.
> >> >>d. V1 client speaking to v1 server.
> >> >>
> >> >>Am I correct in saying that there is nothing in the
> >> >DHCPDISCOVER packet
> >> >>(or 11k location request, etc.) which provides the server with
> >> >>information on the version of the client?
> >> >
> >> >there is no indication of the client version.
> >> >
> >> >>Or is it possible for the server to learn (either
> >out-of-band or
> >> >>in-band) what version the client supports?
> >> >>
> >> >>Some questions:
> >> >>
> >> >>a. Should a client implementation of RFC 3825bis be capable
> >> >of handling
> >> >>both v0 and v1 packets sent by a server?
> >> >
> >> >yes - because the server the client receives can be either
> >> >from a v0 or v1 server.
> >> >
> >> >>b. Should a server implementation of RFC 3825bis always set
> >> >the version
> >> >>number to 1?
> >> >
> >> >this depends on what it wants to convey to the client. If
> >> >the server wants to deliver resolution bits, then a v0
> >> >packet is sent to the client.
> >> >
> >> >If the server wants to send uncertainty bits, the servers
> >> >sends v1 to the client.
> >> >
> >> >>c. Do we understand how existing v0 client implementations
> >> >will behave
> >> >>if they receive a v1 packet from a server?
> >> >
> >> >today - no, this is not completely predictable.
> >> >
> >> >Part of 3825bis will add text to give guidance on the
> >> >desired behavior for each scenario.
> >> >
> >> >James
> >> >
> >> >
> >> >
> >> >_______________________________________________
> >> >Geopriv mailing list
> >> >Geopriv@ietf.org
> >> >https://www.ietf.org/mailman/listinfo/geopriv
> >> >
> >
> >
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
