>As James points out, MUST NOT is probably just "cannot".
I initially thought as Martin did, that "cannot" is the word. But
nothing prevents an OFFER from containing two Option 123s. DHCP (RFC
2131 - which is further clarified in RFC 3396 defining how Options
can be concatenated into one longer single Option value - because
DHCP has length limits on Options) states that if a client receives
an Option, the next reception of that same Option overwrites the
value of the Option in the client.
For example, if the client receives Option 123 with value FOO first,
then receives another Option 123 with value BAR, all the client knows
about is Option 123 value BAR. These consecutive Option 123s can be
from within the same DHCP OFFER, or in subsequent packets, or spaced
a hour apart. The last value overwrites the previous value.
This is different from the same DHCP OFFER containing Options 99 and
123. In this case, because they are two different Options, both are
retained until another 99 or 123 is received and overwrites the previous value.
Therefore, I think the answer is "can" but is pointless. I initially
think this is how it should be stated also, that this doesn't
accomplish anything (i.e., it is pointless to do).
James
>RFC 3315 (v6) forbids it, RFC 2131 and RFC 3396 allow for
>concatenation, which wouldn't make sense.
>
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > Behalf Of James M. Polk
> > Sent: Tuesday, 30 June 2009 9:58 AM
> > To: bernard_aboba@hotmail.com
> > Cc: geopriv@ietf.org
> > Subject: Re: [Geopriv] [geopriv] #10: Server Version Support (was:
> > Should not encourage use of "old" encoding)
> >
> > At 08:51 PM 6/28/2009, geopriv issue tracker wrote:
> > >#10: Server Version Support
> > >---------------------------------------+------------------------------
> > ------
> > > Reporter: martin.thomson@andrew.com | Owner:
> > >
> > > Type: enhancement | Status: new
> > >
> > > Priority: major | Milestone:
> > > draft-ietf-geopriv-3825bis
> > >Component: rfc3825bis | Version:
> > >
> > > Severity: - | Resolution:
> > >
> > > Keywords: |
> > >---------------------------------------+------------------------------
> > ------
> > >
> > >Comment(by bernard_aboba@hotmail.com):
> > >
> > > Client Version Support
> > >
> > > Clients implementing this specification MUST support receiving
> > responses
> > > of versions 0 and 1. Since this specification utilizes the same
> > DHCP
> > > option code as [RFC3825], the option format does not provide a means
> > for
> > > the client to indicate the highest version that it supports to the
> > server.
> > >
> > > Server Version Support
> > >
> > > Servers implementing this specification MUST support sending v0 and
> > v1
> > > responses. The version of the response depends on server
> > configuration.
> > > For example, where few v0 clients are expected, the server could be
> > > configured to send only v1 responses. Where few v1 clients are
> > expected,
> > > the server could be configured to send only v0 responses. Where a
> > mixture
> > > of v0 and v1 clients are expected, the server could be configured to
> > send
> > > either a v0 or v1 response (possibly making the choice based on
> > > information such as the client MAC address). It is NOT RECOMMENDED
> > for a
> > > server to send a response containing both a v0 and a v1 option.
> >
> > everything was fine until this last sentence. If an OFFER (which is a
> > DHCP response) contains two Option values where both Options are
> > identified as the same Option _number_, the second Option overwrites
> > the first Option value. Therefore a server cannot respond to a
> > client by providing both versions, as the first will become
> > immediately useless and forgotten.
> >
> >
> > _______________________________________________
> > Geopriv mailing list
> > Geopriv@ietf.org
> > https://www.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://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
