RE: [Geopriv] DHCP Size

There is nothing preventing a client from requesting options separately; but then there is a need to determine how likely that is.

The only option I'd be concerned about is the civic address option. Languages that require multi-byte characters could be a problem. In particular, I think about the Taiwanese addresses which also have a multi-layer street hierarchy. That would be more of Henning's domain.

> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy@cisco.com]
> Sent: Sunday, 11 March 2007 11:15 AM
> To: James M. Polk
> Cc: geopriv@ietf.org
> Subject: Re: [Geopriv] DHCP Size
>
>
> Makes sense - I was just starting to get a little worried that all
> the options together might be getting close to too big.
>
> Could we try listing all the options that we can imagine might
> reasonable get put in the response to DHCP request from a SIP UA and
> check that there are no surprises.
>
>
> On Mar 10, 2007, at 2:05 PM, James M. Polk wrote:
>
> > At 02:32 PM 3/10/2007, Cullen Jennings wrote:
> >
> >> One thing I have been getting concerned with is the size of DHCP
> >> responses with all the SIP/ECRIT/GEOPRIV etc usages of them. Has
> >> anyone looked at how big one could reasonable get?
> >
> > DHCP has some interesting limitations to Option size (RFC2131),
> > including
> >
> > * the size limitation of any individual Option response
> > (255 bytes I believe)
> > * the size of the aggregate of all responses within a message
> > * and how to concatenate Options (RFC3396)
> >
> > But generally, DHCP responses are limited to 576 bytes for all
> > options (i.e. not just location), unless something special has
> > occurred. This WG cannot assume that only location will be in a
> > DHCP (OFFER or ACK) response, even if that is all that was
> > requested in a DISCOVER, REQUEST or INFORM message. Often many more
> > options will be in that same response message - which is out of the
> > control of the client, but under the control of the server. All of
> > this is capped at 576 bytes (unless something special has
> > occurred). Generally, if an OFFER or ACK response is received in
> > consecutive packets, the second packet's values overwrite the first
> > packets values. In fact, I think any subsequence response with a
> > new value within a specific Option overwrites what was there from
> > the previous response.
> >
> > I think it is possible some folks on this list assume DHCP has the
> > normal MTU of 1500 bytes - and that isn't the case.
> >
> >
> >
> >> _______________________________________________
> >> Geopriv mailing list
> >> Geopriv@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/geopriv
> >
>
> _______________________________________________
> 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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sun, 11 Mar 2007 18:24:15 -0500