geopriv@ietf.org: June 2009

Tuesday, June 30, 2009

Re: [Geopriv] loc-filters additional requirements

I'll note that 4661 isn't totally clear on these points, so there are some assumptions in how this fits together.

For geo/civic, <include/exclude> is a little clumsy in one direction and possibly impossible in the other. Even assuming that we have only RFC 5491 shapes to contend with it's a bit fuzzy.

Requesting geodetic you can't specify ALL shapes because the PA must include these elements. You only want one, but this would result in getting every shape:

<include type="xpath">//gml:Point</include>
<include type="xpath">//gml:Polygon</include>
<include type="xpath">//gs:Circle</include>
<include type="xpath">//gs:Ellipsoid</include>
...
<exclude type="xpath">//ca:CivicAddress</exclude>

Even using an include type of "namespace" wouldn't be advisable, there are two of those. And without doing a lot more reading, I'm not certain that this wouldn't include the entire namespace, which for GML would be ridiculous.

The same argument applies to shape conversion. In my experience, applications tend only support a limited number of shapes by choice. Therefore, it's likely that they will indicate the set of shapes that they support and would prefer. Again, using include would probably result in multiple values.

To that end, I propose two very simple filters:

<locationType>geodetic/civic/any</locationType>

Which is clearly defined to mean that location information is requested in this form; if necessary the PA should convert the information it has into this form.

And:

<geodeticShape>gml:Point</geodeticShape>

Which has similar meaning: provide

I also considered combining the two - to some extent this makes sense if you consider these to have a sort of information hierarchy:

Location - Civic
- Geodetic - Point
- Polygon
- Circle
- ....

That does mess with the syntax a little though.

With respect to location quality, I have a concrete proposal in the draft I referenced (draft-thomson-geopriv-location-quality-04).

To some extent I'm reluctant to request these additions. There are things here that are more generally applicable to continuous-valued presence data (c.f. draft-thomson-simple-cont-presence-val-req). My gut feel is that these sort of additions would greatly increase the complexity of what you are doing. It might be better to leave these out for now and concentrate on the easy ones.

--Martin

> -----Original Message-----
> From: Brian Rosen [mailto:br@brianrosen.net]
> Sent: Wednesday, 1 July 2009 1:01 AM
> To: Thomson, Martin; geopriv@ietf.org
> Subject: RE: [Geopriv] loc-filters additional requirements
>
> Can you not use filter <include> and <exclude> from RFC4661 to
> accomplish
> the geo/civic and shape filters?
>
> That was how I thought we would do it.
>
> I don't have a problem with expanding to cover quality.
>
> A specific proposal might be nice.
>
> Brian
>
> > -----Original Message-----
> > From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> > Behalf Of Thomson, Martin
> > Sent: Tuesday, June 30, 2009 2:37 AM
> > To: geopriv@ietf.org
> > Subject: [Geopriv] loc-filters additional requirements
> >
> > I apologise for not getting these in earlier, but this came out of a
> > discussion that James Polk and I had over his filters draft. We
> > concluded that the draft would become informational and would provide
> a
> > "cookbook" type of assistance to implementers rather than defining
> new
> > filters.
> >
> > To that end, there were a few fairly basic filters that could not be
> > accommodated by the current loc-filters document. We decided to
> raise
> > these in the GEOPRIV WG:
> >
> > 1. location type: A requirement to specify the desired location
> > type: geodetic or civic. This would be a simple addition and would
> > either filter out the undesired type, or - if the PA supported it -
> > allow for the application of (reverse) geo-coding.
> >
> > 2. location shape: For geodetic locations, it might be desirable to
> > have the server perform shape conversion. For instance, on a serving
> > node it's possible to make certain assumptions about shapes that
> result
> > in a smaller shape when converting. This could be significantly
> better
> > than leaving a client to perform any conversions (perhaps based on
> > draft-thomson-geopriv-uncertainty) without that additional
> information.
> >
> > I also have some more general requirements on quality that I would
> like
> > to see included (see draft-thomson-geopriv-location-quality). These
> > might require a somewhat different approach, as they regard the
> > continuous nature of location information. I would have liked for
> > these to be considered, but am pragmatic enough to accept dealing
> with
> > these at a later date.
> >
> > In casting unsubstantiated dispersions about the maturity of this
> > document, these are the issues that I believe were not covered.
> ...and
> > need to be. I hope that this is adequate substantiation.
> >
> > --Martin
> >
> > p.s. We probably also need to go to SIMPLE to discuss the addition of
> a
> > != operator in 4661. There was a good use case for that included in
> > James' document, but my notes don't elaborate on it.
> >

------------------------------------------------------------------------------------------------
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

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

At 01:07 AM 6/30/2009, Thomson, Martin wrote:
>I wasn't directly suggesting sub-options. That wouldn't be
>compatible with our other goals, specifically backward-compatibility.
>
>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.

totally agree here

> Providing both isn't possible.

it doesn't accomplish what one might want it to accomplish, yes.

>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.

Do we want to have text saying something about the current behavior of

"As a matter of practice within DHCP - a server sending one version
of Option 123 towards a client followed by the other version (in the
same response or a separate response) does not allow clients to
retain both versions in memory. Receiving two copies of the same
Option causes the client to replace the old information with the
new information of the same Option (123 in this case)."

This is useful guidance.

James

>--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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Version negotiation . . . Don't we just love this issue :-)

I do not have much to offer other than the OGC Members spent considerable
discussion time defining a standard OGC approach for version negotiation
for use in all OGC web service standards.

And there are still some sticky wickets.

If anyone is interested, I can provide what OGC wording on this topic. May
be helpful.

Carl

> 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
>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] loc-filters additional requirements

Can you not use filter <include> and <exclude> from RFC4661 to accomplish
the geo/civic and shape filters?

That was how I thought we would do it.

I don't have a problem with expanding to cover quality.

A specific proposal might be nice.

Brian

> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of Thomson, Martin
> Sent: Tuesday, June 30, 2009 2:37 AM
> To: geopriv@ietf.org
> Subject: [Geopriv] loc-filters additional requirements
>
> I apologise for not getting these in earlier, but this came out of a
> discussion that James Polk and I had over his filters draft. We
> concluded that the draft would become informational and would provide a
> "cookbook" type of assistance to implementers rather than defining new
> filters.
>
> To that end, there were a few fairly basic filters that could not be
> accommodated by the current loc-filters document. We decided to raise
> these in the GEOPRIV WG:
>
> 1. location type: A requirement to specify the desired location
> type: geodetic or civic. This would be a simple addition and would
> either filter out the undesired type, or - if the PA supported it -
> allow for the application of (reverse) geo-coding.
>
> 2. location shape: For geodetic locations, it might be desirable to
> have the server perform shape conversion. For instance, on a serving
> node it's possible to make certain assumptions about shapes that result
> in a smaller shape when converting. This could be significantly better
> than leaving a client to perform any conversions (perhaps based on
> draft-thomson-geopriv-uncertainty) without that additional information.
>
> I also have some more general requirements on quality that I would like
> to see included (see draft-thomson-geopriv-location-quality). These
> might require a somewhat different approach, as they regard the
> continuous nature of location information. I would have liked for
> these to be considered, but am pragmatic enough to accept dealing with
> these at a later date.
>
> In casting unsubstantiated dispersions about the maturity of this
> document, these are the issues that I believe were not covered. ...and
> need to be. I hope that this is adequate substantiation.
>
> --Martin
>
> p.s. We probably also need to go to SIMPLE to discuss the addition of a
> != operator in 4661. There was a good use case for that included in
> James' document, but my notes don't elaborate on it.
>
> -----------------------------------------------------------------------
> -------------------------
> 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

Monday, June 29, 2009

[Geopriv] loc-filters additional requirements

I apologise for not getting these in earlier, but this came out of a discussion that James Polk and I had over his filters draft. We concluded that the draft would become informational and would provide a "cookbook" type of assistance to implementers rather than defining new filters.

To that end, there were a few fairly basic filters that could not be accommodated by the current loc-filters document. We decided to raise these in the GEOPRIV WG:

1. location type: A requirement to specify the desired location type: geodetic or civic. This would be a simple addition and would either filter out the undesired type, or - if the PA supported it - allow for the application of (reverse) geo-coding.

2. location shape: For geodetic locations, it might be desirable to have the server perform shape conversion. For instance, on a serving node it's possible to make certain assumptions about shapes that result in a smaller shape when converting. This could be significantly better than leaving a client to perform any conversions (perhaps based on draft-thomson-geopriv-uncertainty) without that additional information.

I also have some more general requirements on quality that I would like to see included (see draft-thomson-geopriv-location-quality). These might require a somewhat different approach, as they regard the continuous nature of location information. I would have liked for these to be considered, but am pragmatic enough to accept dealing with these at a later date.

In casting unsubstantiated dispersions about the maturity of this document, these are the issues that I believe were not covered. ...and need to be. I hope that this is adequate substantiation.

--Martin

p.s. We probably also need to go to SIMPLE to discuss the addition of a != operator in 4661. There was a good use case for that included in James' document, but my notes don't elaborate on it.

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

I wasn't directly suggesting sub-options. That wouldn't be compatible with our other goals, specifically backward-compatibility.

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]
>

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]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

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.

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.

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).

--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
>

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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

As James points out, MUST NOT is probably just "cannot".

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

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

> 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.

So the NOT RECOMMENDED should be changed to MUST NOT?

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

Sunday, June 28, 2009

Re: [Geopriv] Issue: version "negotiation"

OK. Strawman text to follow.

Subject: RE: [Geopriv] Issue: version "negotiation"
Date: Sun, 28 Jun 2009 19:36:39 -0500
From: Martin.Thomson@andrew.com
To: bernard_aboba@hotmail.com; gabor.bajko@nokia.com; br@brianrosen.net; mlinsner@cisco.com
CC: geopriv@ietf.org

Can I request that text to this effect be put into the document under a "Server Version Support" (or similar) header. No more need be said on the matter. We tend to overcomplicate things unnecessarily.

From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Saturday, 27 June 2009 11:08 AM
To: gabor.bajko@nokia.com; br@brianrosen.net; mlinsner@cisco.com
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] Issue: version "negotiation"

> In this case, you have a (small) installed base of V0. Any
> new device or server has to implement both V0 and V1 if
> there is a possibility of encountering a V0-only end. It's
> certainly possible to implement V1 only if you allow the
> possibility of failure. For an emergency system, that would
> not be an option, but for other use, it might be okay.

The situation is somewhat different on the client and server so we need to think this through in somewhat more detail.

My understanding is that it is not possible for an RFC 3825bis client to explicitly indicate which version it supports to the server. An RFC 3825bis client will include the same option 55 regardless of the geo-location option version it supports, and for 11k/11y there is no way for a client to signal the highest supported version in the location request. In some cases, v0 and v1 clients may be differentiated by OUI or MAC Address, but this cannot be assumed. As a result, an RFC 3825bis client cold receive either a v0 or a v1 response, and should be prepared to handle either version. It is our (so far unverified) assumption that existing RFC 3825 clients will silently discard a v1 response, but will not suffer other ill-effects (e.g. they won't crash and will still be able to obtain an IP address and utilize other configuration parameters).

On the server side, the lack of an explicit version indication in the request implies that an RFC 3825bis server cannot be assumed to know what version a client supports. However, the server's configuration can be based on prior knowledge of the expected population of v0 and v1 clients.

Where few if any v0 clients are expected, the server can send v1 responses to all requesters. Where out-of-band differentiation is possible, an RFC 3825bis server could send v0 or v1 responses based on out-of-band configuration. Where out-of-band configuration is not possible and v0 clients need to be supported, the server can send v0 responses to all requests.

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

#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.

--
Ticket URL: <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/10#comment:1>
geopriv <http://tools.ietf.org/geopriv/>

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

geopriv@ietf.org

Tuesday, June 30, 2009

Re: [Geopriv] loc-filters additional requirements

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Re: [Geopriv] loc-filters additional requirements

Monday, June 29, 2009

[Geopriv] loc-filters additional requirements

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Sunday, June 28, 2009

Re: [Geopriv] Issue: version "negotiation"

Re: [Geopriv] [geopriv] #10: Server Version Support (was: Should not encourage use of "old" encoding)

Followers

Blog Archive

Contributors