Subject: [Geopriv] [geopriv] #10: Should not encourage use of "old" encoding

From: "geopriv issue tracker" <[email-masked]>
Date: Tue, 23 Jun 2009 00:20:05 -0000

#10: Should not encourage use of "old" encoding
---------------------------------------+------------------------------------
 Reporter:  [email-masked]  |       Owner:                            
     Type:  enhancement                |      Status:  new                       
 Priority:  major                      |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |     Version:                            
 Severity:  -                          |    Keywords:                            
---------------------------------------+------------------------------------
 When creating a new version of 3825, we need to make a statement about how
 to interoperate with the old version.

 Suggestion: permit receipt of the old encoding, but (strongly) discourage
 the sending of it.

 That is:

 Implementations of this specification MUST support receipt of an option
 that includes a version of 0.  Implementations of this specification MUST
 not create or send an option with a version of 0.

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 23 Jun 2009 14:38:54 -0500

>#10: Should not encourage use of "old" encoding

I strongly disagree with this goal.  There may be configurations that 
understand perfectly well what sending a version 0 Option to a client 
means. This should be a local configuration decision.  I don't have 
an issue with adding text providing guidance to prefer that the v1 
Option be sent (and why - and not just "cuz it's better"), but we 
cannot prevent v0 from being sent, which Martin's "MUST" above 
explicitly states.

>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 18:13:58 +0200

>-----Original Message-----
  >From: [email-masked] 
  >[mailto:[email-masked]] On Behalf Of ext James M. Polk
  >Sent: Tuesday, June 23, 2009 12:39 PM
  >To: [email-masked]
  >Subject: Re: [Geopriv] [geopriv] #10: Should not encourage 
  >use of "old" encoding
  >
  >>---------------------------------------+--------------------
  >-----------
  >>---------------------------------------+-----
  >>---------------------------------------+--------------------
  >-----------
  >>---------------------------------------+-----
  >>  When creating a new version of 3825, we need to make a statement 
  >> about how  to interoperate with the old version.
  >>
  >>  Suggestion: permit receipt of the old encoding, but (strongly) 
  >> discourage  the sending of it.
  >>
  >>  That is:
  >>
  >>  Implementations of this specification MUST support receipt of an 
  >> option  that includes a version of 0.  Implementations of this 
  >> specification MUST  not create or send an option with a 
  >version of 0.
  >
  >I strongly disagree with this goal.  There may be 
  >configurations that understand perfectly well what sending a 
  >version 0 Option to a client means. This should be a local 
  >configuration decision.  I don't have an issue with adding 
  >text providing guidance to prefer that the v1 Option be sent 
  >(and why - and not just "cuz it's better"), but we cannot 
  >prevent v0 from being sent, which Martin's "MUST" above 
  >explicitly states.

I also disagree with the proposed text. 
I'd like to see the first MUST be a MAY. I am ok with the second MUST.

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 24 Jun 2009 13:14:23 -0500

>I'd like to see the first MUST be a MAY. I am ok with the second MUST.

The first MUST should be a SHOULD.

The second sentence is a matter of local configuration, which should 
be consistent uniform throughout the local domain.

For example, Cisco San Jose (our main campus) should be RECOMMENDED 
to have the same configuration, but not necessarily the same as the 
Cisco Texas region, or the Cisco North Carolina region. This could be 
a case of configuration migration (i.e., upgrading the config from 
one campus to the next). This "configuration" by any local IT 
department shouldn't violate an RFC, which is being suggested.

---

From: "geopriv issue tracker" <[email-masked]>
Date: Mon, 29 Jun 2009 01:51:42 -0000

#10: Server Version Support
---------------------------------------+------------------------------------
 Reporter:  [email-masked]  |        Owner:                            
     Type:  enhancement                |       Status:  new                       
 Priority:  major                      |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |      Version:                            
 Severity:  -                          |   Resolution:                            
 Keywords:                             |  
---------------------------------------+------------------------------------

Comment(by [email-masked]):

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 29 Jun 2009 18:57:53 -0500

>#10: Server Version Support

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.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 29 Jun 2009 17:02:40 -0700

> immediately useless and forgotten.

So the NOT RECOMMENDED should be changed to MUST NOT?

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 29 Jun 2009 19:06:44 -0500

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.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Tuesday, 30 June 2009 9:58 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Geopriv] [geopriv] #10: Server Version Support (was:
> Should not encourage use of "old" encoding)
> 

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

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 29 Jun 2009 20:37:10 -0500

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 29 Jun 2009 22:31:54 -0500

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

> From: James M. Polk [mailto:[email-masked]]
> Sent: Tuesday, 30 June 2009 11:37 AM
> To: Thomson, Martin; [email-masked]
> Cc: [email-masked]
> > > >---------------------------------------+--------------------------
> ----
> > > ------
> > > >---------------------------------------+--------------------------
> ----
> > > ------
> > > >
> > > >  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
> > > >  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
> > > >  information such as the client MAC address).  It is NOT
> RECOMMENDED
> > > for a

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 30 Jun 2009 00:22:31 -0500

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 30 Jun 2009 01:07:23 -0500

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

> Sent: Tuesday, 30 June 2009 3:23 PM
> Subject: RE: [Geopriv] [geopriv] #10: Server Version Support (was:
> > > > > >  Clients implementing this specification MUST support
> receiving
> > > > > responses
> > > > > >  For example, where few v0 clients are expected, the server
> could
> > > be
> > > > > >  configured to send only v1 responses. Where few v1 clients
> are
> > > > > expected,
> > > > > everything was fine until this last sentence. If an OFFER
> (which is
> > > a
> > > >------------------------------------------------------------------
> ----
> > > --------------------------
> > > >------------------------------------------------------------------
> ----
> > > --------------------------
> > > >[mf2]

---

From: [email-masked]
Date: Tue, 30 Jun 2009 11:49:46 -0400 (EDT)

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

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 30 Jun 2009 15:16:45 -0500

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