I was suggesting that we can define any semantic we like, sub-options or otherwise. Whether DHC - or any other collective of rational engineers - find our choices acceptable is another story entirely.
For now, the best we can do is provide guidance on how a server decides to select V0 or V1. Providing both isn't possible.
I think that Bernard's text was mostly fine, with that small exception. Let me propose an alternative:
""
Server Version Selection
A server that provides location information in either v0 or v1 format cannot provide both formats in the same response. A server uses configuration to determine which version to select. For example, where a mixture of v0 and v1 clients are expected, the server could be configured to send v0 or v1 depending on configuration (possibly making the choice based on information such as the client MAC address). Where few v0 clients are expected, the server could be configured to send only v1 responses.
Servers that opt to send location in v1 format are likely to cause clients that support v0 clients to reject the option. Therefore, where any significant proportion of clients are known to support only v0, this format SHOULD be selected.
""
I've retained Bernard's text with four major changes:
- the offending sentence is removed, instead...
- I've stated the problem: servers have to choose because they can't send both forms
- there is a SHOULD-strength recommendation on using v0 where v0 clients are expected with accompanying justification
- I've change this to version "selection" and removed the MUST on supporting both versions. There is little sense in a server supporting both v0 and v1 if they only ever expect to send one particular version.
--Martin
> -----Original Message-----
> From: James M. Polk [mailto:jmpolk@cisco.com]
> Sent: Tuesday, 30 June 2009 3:23 PM
> To: Thomson, Martin; bernard_aboba@hotmail.com
> Cc: geopriv@ietf.org
> Subject: RE: [Geopriv] [geopriv] #10: Server Version Support (was:
> Should not encourage use of "old" encoding)
>
> in-line
>
> At 10:31 PM 6/29/2009, Thomson, Martin wrote:
> >This is entirely at odds with my reading of 3396. 3396 simply
> >states that some options require concatenation, and those should
> >reference 3396; other options can be split, but only if the sender
> >is certain that the receiver can cope.
>
> DHCP has limits on the size of Options in general, and they haven't
> changed _unless_ concatenation is used, which allows longer values to
> be sent in the same Option.
>
> This is fundamental to DHCP. From RFC 2131
>
> "The values to be passed in an 'option' tag may be too long
> to fit in the 255 octets available to a single option "
>
> 2 instances of the same Option cannot be understood as being separate
> (how could a client interpret it any other way?), and are interpreted
> as the second one replacing the information in first Option of the same
> number.
>
> What is being discussed is having the 1st Option contain a v0 value
> and the 2nd having a v1 value (or the other way around - it doesn't
> matter for this example). How can this be meant as two different
> chunks of data to store separately?
>
>
> >I couldn't find anything specific - rather the whole document
> >supports this conclusion. There is no mention of overriding or
> >replacing anywhere that I can find.
>
> Ok - so let's look at the fairly accurate abstract of RFC 3396, which
> says:
>
> "Multiple instances of the same option are generated when an
> option exceeds 255 octets in size (the maximum size of a
> single
> option) or when an option needs to be split apart in order to
> take
> advantage of DHCP option overloading. When multiple instances
> of the same option appear in the options, file and/or sname
> fields
> in a DHCP packet, the contents of these options are
> concatenated
> together to form a single option prior to processing."
>
> The Intro goes on to state that concatenation existed before 3396 was
> written, but that certain fields needed to be set in order for this
> to happen, and that there wasn't any mention in 2131 as to 'if there
> are multip;le instances of the same Option code in the same
> server-to-client response (i.e., DHCP OFFER or INFORM) that there was
> no guidance in 2131 as to how to reorder the longer than 255 byte
> values within that concatenated Option, that 3396 clarifies this.
>
> So, 3396 further clarifies that 255 is the maximum Option size,
> unless concatenation more than one Option code in the same response
> packet/message is present., and that 3396 will given an order to how
> the concatenated value should be put back together. This doesn't say
> anything about having the same Option code (123 in this case) in a
> response message twice mean 2 different things, which would be the
> case were a OFFER to contain both a v1 and a v0 Option value.
>
> What this is describing is a suboption capability, i.e., you have two
> version of Option 123, and you have to pay attention to the
> versioning field within the Option 123 OFFER to figure out how to
> parse the information contained within that one OFFER.
>
> being able to have more than one version at either the client or
> server of an existing Option (123) is the same thing as having a
> suboption of an Option (123), so I'll use the term suboptions from
> now on for this.
>
> I tried that years ago when I wrote an ID that created a means of
> providing more than one type of URI to be offered in an OFFER here
> (from 2006),
> http://www.ietf.org/internet-drafts/draft-polk-dhc-uri-03.txt
> with the client indicating which URI it wanted as a suboption of the
> "URI Option". DHC WG just puked all over that one, as they didn't
> like (actually they hated) the idea of not only asking for, but
> having the ability to offer suboptions within higher level Options.
> Their distain was not at all with how I wrote the ID, but at this
> concept of suboptions -- which I didn't think was a bad idea.
>
> They did, and the ID died in a flaming ball of fire.
>
>
> >It would be possible to define an option 123 semantic that allowed
> >for the behaviour you describe, but that would need to be specific
> >to the option definition (i.e. option 123 can be a multiple of 16
> >octets, containing different versions of the encoding in sequence;
> >the last encoding that the client understands should be used).
>
> see above for the track record of suboptions -- which this would be
>
>
> >--Martin
> >
> > > -----Original Message-----
> > > From: James M. Polk [mailto:jmpolk@cisco.com]
> > > Sent: Tuesday, 30 June 2009 11:37 AM
> > > To: Thomson, Martin; 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 07:06 PM 6/29/2009, Thomson, Martin wrote:
> > > >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
> > >
> >
> >----------------------------------------------------------------------
> --------------------------
> >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]
>
------------------------------------------------------------------------------------------------
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
