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

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 1 Jul 2009 09:33:44 -0500

> 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

I agree with providing guidance like this in an obviously non-normative 
way - it's not something everyone knows.

Thanks,

Spencer

---

From: "geopriv issue tracker" <[email-masked]>
Date: Wed, 01 Jul 2009 17:07:40 -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]):

 Revision:

 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 a v1 response (possibly making the choice based on
 information such as the client MAC address).

 As a matter of practice within DHCP, a server sending one version of
 Option 123 to 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).  Therefore it is not useful for a server to send both
 v0 and v1 options to the client.

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 1 Jul 2009 18:17:37 -0500

Except for the fact that this is only possible in _different_ DHCP responses.  If it were in the same response, concatenation would be applied and client behaviour would be undefined (and unpredictable).

> -----Original Message-----
> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Thursday, 2 July 2009 12:34 AM
> To: Thomson, Martin; [email-masked]; James M. Polk
> 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: Thu, 02 Jul 2009 00:40:45 -0500

I call this one as we are in violent agreement...

agreed?

At 06:17 PM 7/1/2009, Thomson, Martin wrote:
>Except for the fact that this is only possible in _different_ DHCP 
>responses.  If it were in the same response, concatenation would be 
>applied and client behaviour would be undefined (and unpredictable).
>
>_______________________________________________
>Geopriv mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Jul 2009 18:35:43 -0500

Sure, on the technical point.

I contend that including text in the document (as proposed) might instead by confusing.

Certain major DHCP implementations don't ever make a second request and so would not be able to benefit from the suggestion.  I suspect also that if the second response is the unsupported version, the first option, supported or not, is likely to be destroyed.

> From: James M. Polk [mailto:[email-masked]]
> Sent: Thursday, 2 July 2009 3:41 PM
> To: Thomson, Martin; Spencer Dawkins; [email-masked]
> Cc: [email-masked]
> > > > Do we want to have text saying something about the current
> behavior
> > > of
> > > >
> > > >         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

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 02 Jul 2009 22:26:53 -0500

At 06:35 PM 7/2/2009, Thomson, Martin wrote:
>Certain major DHCP implementations don't ever make a second request 
>and so would not be able to benefit from the suggestion.

err, then we might not be agreeing to the same thing, since this 
second request will *always* occur when the client refreshes its 
lease (or sooner).

>I suspect also that if the second response is the unsupported 
>version, the first option, supported or not, is likely to be destroyed.

this is a problem that I hope the new text attempts to prevent - by 
saying sending two versions of the same Option code (123 in this 
case) doesn't achieve what one may want (that both are stored), and 
instead means the second piece of data overwrites the first. If the 
second is not supported, and destroys what was stored, this indeed 
would be a very bad thing.

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 2 Jul 2009 22:38:35 -0500

You can't rely on the server being able to send a second option.  If it's at the end of a lease, that could be hours away; far too long a time to be useful.

You also cannot rely on a client ignoring a version that it doesn't support and retaining the version that it does.  It will keep the most recent, and if that's not supported, then it will have to assume that it can't use any location information.  After all, it doesn't necessarily know that it hasn't moved.

It's ultimately pointless attempting to use multiple messages to deal with this problem.

--Martin 

> Sent: Friday, 3 July 2009 1:27 PM
> Subject: RE: [Geopriv] [geopriv] #10: Server Version Support (was:
> > > > > >         "As a matter of practice within DHCP - a server
> sending
> > > one
> > > > > > version
> > > >------------------------------------------------------------------
> ----
> > > --------------------------
> > > >------------------------------------------------------------------
> ----
> > > --------------------------
> > > >[mf2]

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 03 Jul 2009 00:17:52 -0500

At 10:38 PM 7/2/2009, Thomson, Martin wrote:
>You can't rely on the server being able to send a second option.

correct, but I didn't think I implied that.

>If it's at the end of a lease, that could be hours away; far too 
>long a time to be useful.
>
>You also cannot rely on a client ignoring a version that it doesn't 
>support and retaining the version that it does.

I think the behavior is pretty much set, get the first - use the 
first, until a second is received; then purge the first and replace 
it with the second, then use the second; and so on...

>It will keep the most recent, and if that's not supported, then it 
>will have to assume that it can't use any location information.

agreed, and this should be avoided

>After all, it doesn't necessarily know that it hasn't moved.
>

I agree

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 3 Jul 2009 00:30:58 -0500

Excellent :)

Since we agree on this, can we agree that this text isn't helpful:

"
As a matter of practice within DHCP, a server sending one version of Option 123 to 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). Therefore it is not useful for a server to send both v0 and v1 options to the client.
"

The first sentence implies (to me) that it's possible to send both versions, which is a little misleading.  I'm pretty sure that the second is only true if the copies are in different messages.

And instead use the text that I proposed.

<http://www.ietf.org/mail-archive/web/geopriv/current/msg07431.html>

Maybe changing the first sentence to:

A server that provides location information cannot provide both v0 and v1 formats.

--Martin

> Sent: Friday, 3 July 2009 3:18 PM

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 03 Jul 2009 00:44:14 -0500

At 12:30 AM 7/3/2009, Thomson, Martin wrote:
>Option 123 to 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). Therefore it is 
>not useful for a server to send both v0 and v1 options to the client.
>"
>
>The first sentence implies (to me) that it's possible to send both versions,

I think the first sentence says "it's stupid to do this, so don't try".

I think this is still useful.

>which is a little misleading.  I'm pretty sure that the second is 
>only true if the copies are in different messages.
>

---

From: "geopriv issue tracker" <[email-masked]>
Date: Fri, 03 Jul 2009 19:11:03 -0000

Incorporating comments. How about this?

 Client Version Support

 Server Version Selection

 A DHCP server that provides location information cannot provide options
 with both v0 and v1 formats in the same response.  This is not useful
 since receiving two copies of the same Option (either in the same response
 or a separate response) causes a DHCP client to replace the information in
 the old Option with the information in the new Option.

 A server uses configuration to determine which version to send in a
 response.  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, by default
 the server SHOULD send a v0 response.

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

---

From: "James M. Polk" <[email-masked]>
Date: Sat, 04 Jul 2009 15:09:31 -0500

>#10: Server Version Support

I would add one clarification near the end of the last paragraph. see 
in-line below

>  that support v0 clients to reject the Option.

This scenario results in the client not having location information 
with no ability to indicate to the server this version (1) was not supported.

>Therefore, where any

NOTE: I would also use another word than "significant" in the 
sentence above, as that could be interpreted as "a majority" of 
clients, when in reality every v0 only client will reject any v1 
Option, meaning each will be without location with no way to tell 
anyone about it. This is a situation I think we want to avoid, and I 
wish there was a better way to do this, but there isn't.

---

From: "geopriv issue tracker" <[email-masked]>
Date: Sun, 05 Jul 2009 04:34:12 -0000

Incorporating suggestions from James.

 Client Version Support

 Server Version Selection

 A DHCP server that provides location information cannot provide options
 with both v0 and v1 formats in the same response. This is not useful since
 receiving two copies of the same Option (either in the same response or a
 separate response) causes a DHCP client to replace the information in the
 old Option with the information in the new Option.

 Servers that opt to send location in v1 format are likely to cause clients
 that support only v0 to reject the Option.  This results in a v0-only
 client not obtaining location information, with no ability to indicate to
 the server that v1 was unsupported.  Therefore, in situations where some
 clients are known to support only v0, by default the server SHOULD send a
 v0 response.

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

---

From: "James M. Polk" <[email-masked]>
Date: Sun, 05 Jul 2009 01:48:24 -0500

this is good

thanks

james

---

From: "geopriv issue tracker" <[email-masked]>
Date: Tue, 07 Jul 2009 02:02:14 -0000

#10: Server Version Support
---------------------------------------+------------------------------------
 Reporter:  [email-masked]  |        Owner:                            
     Type:  enhancement                |       Status:  closed                    
 Priority:  major                      |    Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |      Version:  1.0                       
 Severity:  -                          |   Resolution:  fixed                     
 Keywords:                             |  
---------------------------------------+------------------------------------
Changes (by [email-masked]):

  * status:  new => closed
  * version:  => 1.0
  * resolution:  => fixed

Comment:

 Is this issue resolved?

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

---

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 6 Jul 2009 19:28:55 -0700

The IETF 75 submission deadline is fast approaching (less than 7 writing
days away).  

At this point, TRAC reports 10 tickets relating to RFC 3825bis.   

Most of them do not yet have text proposals associated with them. 
(Potential exceptions:  #10, perhaps #6). 

Among other things, this leaves the tickets feeling lonely. 

Given the amount of discussion we have had relating to some of the tickets, 
if you have been considering sending a proposed resolution to the list, 
there is no better time to do this than right now.   Not only will this 
give the WG some time to discuss and improve upon your suggestion, but it 
also will give me some time to add the changes prior to the deadline.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 7 Jul 2009 18:57:23 +0200

So assuming you are both referring to the MUST that relates to receipt of version 0 as well as version 1.

If you downgrade this you automatically lose compatibility. You can only do this if you are confident that you are in an environment where it is impossible for there to be v0 senders. 

As the normal practice is to write some sort of explanation whenever SHOULD or RECOMMENDED is used (they mean the same thing), explaining the circumstances under which the requirement is not expected to exist, then that is what you will have to say in the text.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: Wednesday, June 24, 2009 7:14 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Geopriv] [geopriv] #10: Should not encourage 
> use of "old" encoding
> 
> At 11:13 AM 6/24/2009, [email-masked] wrote:
> >
> >
> >   >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
> >   >
> >   >At 07:20 PM 6/22/2009, geopriv issue tracker wrote:
> >   >>#10: Should not encourage use of "old" encoding
> >   >>---------------------------------------+--------------------
> >   >-----------
> >   >>---------------------------------------+-----
> >   >>  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.
> >   >
> >   >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.
> 
> 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.
> 
> 
> 
> >   >>--
> >   >>Ticket URL: 
> <http://trac.tools.ietf.org/wg/geopriv/trac/ticket/10>