Subject: [Geopriv] Datum field changes in RFC 3825bis (affecting Sections 2, 2.1 and 6.2)

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Jun 2009 21:24:37 -0700

Can someone enter a ticket for this? 

Below are the proposed changes.  Please review.  The -01 strawman with these
changes is available here:
http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3825bis-01.txt

In Section 2, change:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code 123    |      16       |   LaRes   |     Latitude      +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Latitude (cont'd)              |    LoRes  |   +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Longitude                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT  |   AltRes  |                Altitude                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Alt (cont'd) |     Datum     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

To:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Code 123    |      16       |   LaRes   |     Latitude      +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Latitude (cont'd)              |    LoRes  |   +
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             Longitude                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   AT  |   AltRes  |                Altitude                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Alt (cont'd) |Datum| Res |Ver|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In Section 2.1, change:

   The Datum byte has 256 possibilities, of which 3 have been registered

To: 

   The Datum field is 3 bits, providing 8 possibilities, of which 3 have
   been registered 

At the end of Section 2.1 add:

   The Res field which is 3 bits, is reserved.  These bits have been
   used by [IEEE-802.11y], but are not defined within this
   specification.

   The Ver field is two bits, and represents a version field, providing
   for 4 potential versions.

In Section 6.2, add:

[IEEE-802.11y]
          Information technology - Telecommunications and information
          exchange between systems - Local and metropolitan area
          networks - Specific requirements - Part 11: Wireless LAN
          Medium Access Control (MAC) and Physical Layer (PHY)
          specifications Amendment 3: 3650-3700 MHz Operation in USA,
          November 2008.

> Date: Wed, 10 Jun 2009 15:56:49 -0500
> To: [email-masked]; [email-masked]; [email-masked]
> From: [email-masked]
> Subject: RE: Text for 3825bis
> CC: [email-masked]
> 
> Bernard
> 
> I assume you can make the edits about splitting the datum field into 
> 3 parts, as I don't see that as controversial, and I think you have 
> much of the idea from Richard, and can look in section 2 of
> http://www.ietf.org/internet-drafts/draft-polk-geopriv-3825-update-00.txt
> for how the datum field is being broken up.
> 
> James

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 10 Jun 2009 23:29:28 -0500

Hi Bernard,

I think that you have these back to front.  The version tags need to go in the MSB, so that old versions using the LSBs aren’t affected.  Other than that, I think that it’s OK.

Is it worth pointing out that the version tags can change anything, including the length of the entire option?

--Martin

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, 11 June 2009 2:25 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: Thomson, Martin; [email-masked]
Subject: Datum field changes in RFC 3825bis (affecting Sections 2, 2.1 and 6.2)

In Section 2, change:

    0                   1                   2                   3

To:

    0                   1                   2                   3

In Section 2.1, change:

To: 

In Section 6.2, add:

[IEEE-802.11y]

> for how the datum field is being broken up.

------------------------------------------------------------------------------------------------
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: Bernard Aboba <[email-masked]>
Date: Wed, 10 Jun 2009 21:47:57 -0700

Thanks for pointing out the error. 

I guess we're pointing out that implementers should check the length field, then look at the 2 most significant bits 
of the last octet to determine the version, rather than just assuming that the length = 16. 

Should we point out that RFC 3825 was version 0, and that this specification defines version 1?
Some text probably belongs in the IANA considerations section describing how version numbers are allocated
(presumably by Standards Action, no?)

Subject: RE: Datum field changes in RFC 3825bis  (affecting Sections 2, 2.1 and 6.2)
Date: Wed, 10 Jun 2009 23:29:28 -0500
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]

Hi Bernard,

I think that you have these back to front.  The version tags
need to go in the MSB, so that old versions using the LSBs aren’t affected. 
Other than that, I think that it’s OK.

Is it worth pointing out that the version tags can change anything,
including the length of the entire option?

--Martin

From: Bernard Aboba
[mailto:[email-masked]] 

Subject: Datum field changes in RFC 3825bis (affecting Sections 2, 2.1
and 6.2)

Below are the proposed changes.  Please review.  The -01 strawman
with these

In Section 2, change:

0                  
1                  
2                  
3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
0 1

   |   Code 123   
|      16      
|   LaRes   |    
Latitude      +

|               
Latitude
(cont'd)             
|    LoRes  |   +

|                            
Longitude                        
|

   |   AT  |   AltRes 
|               
Altitude                  
|

   |  Alt (cont'd) |    
Datum     |

To:

0                  
1                  
2                  
3

    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
0 1

   |   Code 123   
|      16      
|   LaRes   |    
Latitude      +

   |               
Latitude
(cont'd)             
|    LoRes  |   +

|                            
Longitude                        
|

   |   AT  |   AltRes 
|               
Altitude                  
|

In Section 2.1, change:

   The Datum byte has 256 possibilities, of which 3 have been
registered

To: 

   The Datum field is 3 bits, providing 8 possibilities, of which 3
have

   been registered 

   The Res field which is 3 bits, is reserved.  These bits have
been

   specification.

   The Ver field is two bits, and represents a version field,
providing

In Section 6.2, add:

[IEEE-802.11y]

          Information technology -
Telecommunications and information

          exchange between systems
- Local and metropolitan area

          networks - Specific
requirements - Part 11: Wireless LAN

          Medium Access Control
(MAC) and Physical Layer (PHY)

          specifications Amendment
3: 3650-3700 MHz Operation in USA,

          November 2008.

[mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 10 Jun 2009 23:55:42 -0500

The last octet, or the 16th?  I think that you mean 16th.  That’s an important distinction to make as well.

Yes we should point out that RFC 3825 was version 0.  I don’t think that we need to create a registry, but noting that new versions require an update to the current document is sensible.

--Martin

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, 11 June 2009 2:48 PM
To: Thomson, Martin; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Datum field changes in RFC 3825bis (affecting Sections 2, 2.1 and 6.2)

________________________________

Hi Bernard,

--Martin

In Section 2, change:

    0                   1                   2                   3

To:

    0                   1                   2                   3

In Section 2.1, change:

To: 

In Section 6.2, add:

[IEEE-802.11y]

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Jun 2009 22:34:41 -0700

I guess it depends on what promise we're making with respect to the location of the version field in the future. 

Typically a version field is in the beginning of the packet, so its location is the same, regardless of the packet length. 

In this case, if we're saying that the ver field will always be in the 16th octet, then you look there, regardless of the value of the length field.  

In that case, if the length field < 16 octets, then you need to assume the packet is malformed and discard it. 

An alternative would be to say that the ver field will always be in the last byte.  So you check the length field and then look for it there.  In that case, it is possible for the length field to be < 16 octets (though not for the version specified in this document). 

Subject: RE: Datum field changes in RFC 3825bis  (affecting Sections 2, 2.1 and 6.2)
Date: Wed, 10 Jun 2009 23:55:42 -0500
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]

The last octet, or the 16th?  I think that you mean
16th.  That’s an important distinction to make as well.

Yes we should point out that RFC 3825 was version 0.  I don’t
think that we need to create a registry, but noting that new versions require an
update to the current document is sensible.

--Martin

To: Thomson, Martin; [email-masked]; [email-masked];
[email-masked]

Cc: [email-masked]

Subject: RE: Datum field changes in RFC 3825bis (affecting Sections 2,
2.1 and 6.2)

I guess we're pointing out that implementers should check the length field,
then look at the 2 most significant bits 

of the last octet to determine the version, rather than just assuming that the
length = 16. 

Should we point out that RFC 3825 was version 0, and that this specification
defines version 1?

Some text probably belongs in the IANA considerations section describing how
version numbers are allocated

Subject: RE: Datum field changes in RFC
3825bis (affecting Sections 2, 2.1 and 6.2)

To: [email-masked]; [email-masked]; [email-masked];
[email-masked]

CC: [email-masked]

Hi Bernard,

I think that you have these back to front.  The version
tags need to go in the MSB, so that old versions using the LSBs aren’t
affected.  Other than that, I think that it’s OK.

Is it worth pointing out that the version tags can change
anything, including the length of the entire option?

--Martin

From: Bernard Aboba

 

In Section 2, change:

0                  
1                  
2                  
3

   |   Code 123   
|      16      
|   LaRes   |    
Latitude      +

   |               
Latitude
(cont'd)             
|    LoRes  |   +

|                            
Longitude                        
|

   |   AT  |   AltRes 
|               
Altitude                  
|

   |  Alt (cont'd) |    
Datum     |

To:

0                  
1                  
2                  
3

   |   Code 123   
|      16      
|   LaRes   |    
Latitude      +

|               
Latitude
(cont'd)             
|    LoRes  |   +

|                            
Longitude                        
|

   |   AT  |   AltRes 
|               
Altitude                  
|

In Section 2.1, change:

To: 

   been registered 

   specification.

In Section 6.2, add:

[IEEE-802.11y]

          Information technology -

          exchange between systems

          networks - Specific

          Medium Access Control

          specifications Amendment

          November 2008.

 

  [mf2]

[mf2]

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 11 Jun 2009 00:42:51 -0500

Indeed, we need to make the promise clear.  …and neither option is optimal.  

Personally, I’d prefer to fix its position relative to the start of the option, not the end.  Having it relative to the end in effect makes its placement dynamic.  I consider it unlikely that we’ll shrink the option such that padding to 16 octets will be a problem (more unlikely even than the existence of version 2!) and I believe that it’s easier on existing implementations to have it fixed at 16, not n-1.

--Martin

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, 11 June 2009 3:35 PM
To: Thomson, Martin; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: Datum field changes in RFC 3825bis (affecting Sections 2, 2.1 and 6.2)

--Martin

Hi Bernard,

--Martin

In Section 2, change:

    0                   1                   2                   3

To:

    0                   1                   2                   3

In Section 2.1, change:

To: 

In Section 6.2, add:

[IEEE-802.11y]

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Jun 2009 16:41:55 -0500

Given that this bis doc is going to obsolete 3825, then this bis doc 
is defining both version 0 and 1 - because someone can still choose 
(and I'm not sure why they would, but they could) to implement only 
what works in version 0 of this spec.

That this doc specifies both v0 and v1 needs to be said if anything 
is said., and I think something needs to be said - given we're 
obsoleting 3825 "for cause".

At 11:47 PM 6/10/2009, Bernard Aboba wrote:
>I guess we're pointing out that implementers should check the length 
>field, then look at the 2 most significant bits
>Some text probably belongs in the IANA considerations section 
>describing how version numbers are allocated
>----------
>I think that you have these back to front.  The version tags need to 
>go in the MSB, so that old versions using the LSBs aren't 
>affected.  Other than that, I think that it's OK.
>
>
>

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 11 Jun 2009 16:43:45 -0500

>(presumably by Standards Action, no?)

I agree that we ought to mandate a Standards Track RFC is required to 
change, update or obsolete this specification.

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 19 Jun 2009 18:14:20 +0200

I dont agree with the specifics of:

> Given that this bis doc is going to obsolete 3825, then this 
> bis doc is defining both version 0 and 1 - because someone 
> can still choose (and I'm not sure why they would, but they 
> could) to implement only what works in version 0 of this spec.
> 
> That this doc specifies both v0 and v1 needs to be said if 
> anything is said., and I think something needs to be said - 
> given we're obsoleting 3825 "for cause".
>

The fact that the bis exists does not remove RFC 3825 from existence, it merely labels it obsolete. Moreover implementations to RFC 3825 continue to exist. There is no automatic requirement that an implementation conformant to RFC 3825 is also conformant to the bis. What we need is compatibility. So in effect two options exist for each change (between which the group has to decide) while maintaining compatibility:

1)	The existing behaviour is decided by the group to be useful for new implementations, in addition to the proposed new behaviour. In which case, the bis document defines both (for both sender and receiver).

2)	The existing behaviour is decided by the group to be not preferred. In that case the new behaviour is specified. For compatibility with existing implementations, new implementations have to be required to receive what old implementations send.

There is a third option that the existing behaviour is so broken that existing implementations do not work with each other, in which case any compatibility requirements are moot. This however does not apply in this case.

regards

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of James M. Polk
> Sent: Thursday, June 11, 2009 10:42 PM
> To: Bernard Aboba; [email-masked]; 
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [Geopriv] Datum field changes in RFC 3825bis 
> (affecting Sections 2, 2.1 and 6.2)
> 
> Given that this bis doc is going to obsolete 3825, then this 
> bis doc is defining both version 0 and 1 - because someone 
> can still choose (and I'm not sure why they would, but they 
> could) to implement only what works in version 0 of this spec.
> 
> That this doc specifies both v0 and v1 needs to be said if 
> anything is said., and I think something needs to be said - 
> given we're obsoleting 3825 "for cause".
> 
> >field, then look at the 2 most significant bits of the last octet to 
> >determine the version, rather than just assuming that the 
> length = 16.
> >
> >describing how version numbers are allocated (presumably by 
> Standards 
> >Action, no?)
> >
> >
> >----------
> need to go 
> >in the MSB, so that old versions using the LSBs aren't 
> affected.  Other 
> >Below are the proposed changes.  Please review.  The -01 
> strawman with 
> >these changes is available here:
> >http://www.drizzle.com/~aboba/GEOPRIV/draft-ietf-geopriv-rfc3
> 825bis-01.
> >txt
> >
> >In Section 2, change:
> >
> >     0                   1                   2                   3
> http://www.ietf.org/internet-drafts/draft-polk-geopriv-3825-update-0
> > > 0.txt for how the datum field is being broken up.
> > >
> > > James
> >
> >
> >
> >-------------------------------------------------------------
> ----------
> >------------------------- This message is for the designated 
> recipient 
> >only and may contain privileged, proprietary, or otherwise private 
> >information.
> immediately 
> >and delete the original.  Any unauthorized use of this email is 
> >prohibited.
> >-------------------------------------------------------------
> ----------
> >-------------------------
> >[mf2]
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 21 Jun 2009 18:59:54 -0500

Hi Keith,

I don't see any practical difference between the outcome of 1 and 2.  It's an exercise in labelling that materially changes nothing.  We waste too much time on labelling.

--Martin

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Saturday, 20 June 2009 2:14 AM
> To: James M. Polk; Bernard Aboba; Thomson, Martin; [email-masked];
> [email-masked]
> Cc: [email-masked]
> Subject: RE: [Geopriv] Datum field changes in RFC 3825bis (affecting
> Sections 2, 2.1 and 6.2)
> 
> The fact that the bis exists does not remove RFC 3825 from existence,
> it merely labels it obsolete. Moreover implementations to RFC 3825
> continue to exist. There is no automatic requirement that an
> implementation conformant to RFC 3825 is also conformant to the bis.
> What we need is compatibility. So in effect two options exist for each
> change (between which the group has to decide) while maintaining
> compatibility:
> 
> 1)	The existing behaviour is decided by the group to be useful for
> new implementations, in addition to the proposed new behaviour. In
> which case, the bis document defines both (for both sender and
> receiver).
> 
> 2)	The existing behaviour is decided by the group to be not
> preferred. In that case the new behaviour is specified. For
> compatibility with existing implementations, new implementations have
> to be required to receive what old implementations send.
> 
> There is a third option that the existing behaviour is so broken that
> existing implementations do not work with each other, in which case any
> compatibility requirements are moot. This however does not apply in
> this case.
> 
> regards
> 
> Keith
> 
> > >    |                             Longitude
> > >    |                             Longitude

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 23 Jun 2009 02:04:13 +0200

Read the text. 

In 1) you define both a sending requirement and a receiving requirement for the existing codepoint. In 2 you define only a receiving requirement, and do not allow new implementations to send it (i.e. it is there only for dealing with legacy implementations that send it). 

regards

Keith

> From: Thomson, Martin [mailto:[email-masked]] 
> Sent: Monday, June 22, 2009 1:00 AM
> To: DRAGE, Keith (Keith); James M. Polk; Bernard Aboba; 
> Subject: RE: [Geopriv] Datum field changes in RFC 3825bis 
> I don't see any practical difference between the outcome of 1 
> and 2.  It's an exercise in labelling that materially changes 
> nothing.  We waste too much time on labelling.
> 
> --Martin
> 
> > > (and I'm not sure why they would, but they
> > existing implementations do not work with each other, in which case 
> > any compatibility requirements are moot. This however does 
> not apply 
> > in this case.
> > 
> > regards
> > 
> > Keith
> > 
> > > To: Bernard Aboba; [email-masked]; [email-masked]; 
> > > [email-masked]
> > > Cc: [email-masked]
> > > (and I'm not sure why they would, but they
> > > >I guess we're pointing out that implementers should check the 
> > > >length field, then look at the 2 most significant bits 
> of the last 
> > > >octet to determine the version, rather than just 
> assuming that the
> > > length = 16.
> > > >
> > > >Subject: Datum field changes in RFC 3825bis (affecting 
> Sections 2,
> > > >2.1 and 6.2)
> > > >
> > > >
> > > >
> > > >     0                   1                   2           
> > > >     0                   1                   2

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 22 Jun 2009 19:16:10 -0500

Since you clarify it, maybe it makes a difference.  Of course, the whole reason that we're doing this is because the old specification couldn't be used to create a sensible message in many cases.  Certainly we shouldn't be encouraging people to try to send the old encoding: that would be daft.

I'll create an issue: Should not encourage use of "old" encoding

> Sent: Tuesday, 23 June 2009 10:04 AM
> To: Thomson, Martin; James M. Polk; Bernard Aboba; [email-masked];
> [email-masked]
> Cc: [email-masked]
> In 1) you define both a sending requirement and a receiving requirement
> for the existing codepoint. In 2 you define only a receiving
> requirement, and do not allow new implementations to send it (i.e. it
> is there only for dealing with legacy implementations that send it).
> 
> regards
> 
> Keith
> 
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +
> > > > >    |                Latitude (cont'd)              |    LoRes
> |
> > > +
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +
> > > > >    |                             Longitude
> > > |
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +
> > > > >    |   AT  |   AltRes  |                Altitude
> > > |
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +
> > > > >    |  Alt (cont'd) |     Datum     |
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +
> > > > >    |                Latitude (cont'd)              |    LoRes
> |
> > > +
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +
> > > > >    |                             Longitude
> > > |
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +
> > > > >    |   AT  |   AltRes  |                Altitude
> > > |
> > > > >
> > > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +-
> > > +

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Jun 2009 00:07:34 -0700

Martin said:

"Certainly we shouldn't be encouraging people to try to send the old encoding". 

There are a number of potential cases here:

a. Legacy (v0) client speaking to v1 server. 
b. Legacy (v0) client speaking to v0 server. 
c. V1 client speaking to v0 server. 
d. V1 client speaking to v1 server. 

Am I correct in saying that there is nothing in the DHCPDISCOVER packet (or 11k location request, etc.) which provides the server with information on the version of the client? 
Or is it possible for the server to learn (either out-of-band or in-band) what version the client supports? 

Some questions:

a. Should a client implementation of RFC 3825bis be capable of handling both v0 and v1 packets sent by a server? 
b. Should a server implementation of RFC 3825bis always set the version number to 1? 
c. Do we understand how existing v0 client implementations will behave if they receive a v1 packet from a server?

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 23 Jun 2009 02:19:17 -0500

There are no per-option version indications in DHCP.  For the most part, DHCP options are simple enough not to need versioning – it seems that versioning is expected to be done by consuming another option code and deprecating the old one (an approach I am beginning to appreciate heartily).

We aren’t able to signal compliance in DHCP (*).  I can’t speak for 11k, but I’d imagine that the story would be similar.

My perspective:

a.       Yes.

b.      Yes.

c.       My understanding is that a sensible v0 client will discard the information because it will interpret this as a “datum” that it does not support.  If someone actually has knowledge of an implementation that does other than this, then it would be a bug and we might look at that implementation specifically if it were especially widely deployed.

--Martin

(*) not strictly true: it used to be that DHCP (BOOTP?) clients sent up the options that they wanted in a request.  This is long deprecated by option 55.  We could hack something with that, but we’d be risking the ire of all sane DHC experts.

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Tuesday, 23 June 2009 5:08 PM
To: Thomson, Martin; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Issue: version "negotiation"

Martin said:

Some questions:

---

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

At 02:07 AM 6/23/2009, Bernard Aboba wrote:
>Am I correct in saying that there is nothing in the DHCPDISCOVER 
>packet (or 11k location request, etc.) which provides the server 
>with information on the version of the client?

there is no indication of the client version.

>Or is it possible for the server to learn (either out-of-band or 
>in-band) what version the client supports?
>
>Some questions:
>
>a. Should a client implementation of RFC 3825bis be capable of 
>handling both v0 and v1 packets sent by a server?

yes - because the server the client receives can be either from a v0 
or v1 server.

>b. Should a server implementation of RFC 3825bis always set the 

this depends on what it wants to convey to the client. If the server 
wants to deliver resolution bits, then a v0 packet is sent to the client.

If the server wants to send uncertainty bits, the servers sends v1 to 
the client.

>c. Do we understand how existing v0 client implementations will 
>behave if they receive a v1 packet from a server?

today - no, this is not completely predictable.

Part of 3825bis will add text to give guidance on the desired 
behavior for each scenario.

James

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Jun 2009 07:16:40 -0700

> behavior for each scenario.

By "unpredictable" do you mean "untested" or "could vary
between implementations"?

In the case of .11 implementations, the code for the v0

client could be present in firmware or a kernel mode
driver.  That implies that mis-behavior can have serious
consequences. 

We can address cases c and d in RFC 3825bis, and case b
is inherited from RFC 3825. 

Do we have the same freedom with respect to case a?

---

From: [email-masked]
Date: Tue, 23 Jun 2009 15:28:35 +0100

> between implementations"?

As I understand it the response should be predictable, i.e. it *should* 
ignore the information because it doesn't know how to parse it. 

It's just unfortunately not well documented in 3825, because 3825 omits to 
give specific guidance as to what a client should do if it receives an 
unrecognised datum.

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

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

>between implementations"?

since there is no guidance in 3825 on what to do if a v0 client 
receives a datum it does not understand, I don't believe we can state 
with certainty what the outcome would be.

That said, (somewhat reaching) common sense says a v0 client 
receiving a datum value that it does not understand (anything above 
datum value=3), the client will most likely discard the Option.

The only exception I can think of is that an implementation may 
default back to WGS84 (4326 or 4979), though nothing in 3825 says to 
do this. This may be an implementation specific "common sense" 
approach that wasn't documented openly.

>driver.  That implies that mis-behavior can have serious

There has to be "what to do if I (the client) receive a datum > 3... 
I would assume that behavior is what happens, though there is no 
known documented open behavior (other than likely to discard the 
Option in total).

>Do we have the same freedom with respect to case a?

for (a), if the server sends a v1 Option, then we're exactly where we 
are now if a v0 server sends a Option value with a datum > 3.  At 
that point, datum=4 is the same as datum=65 or 129 or whatever.

BTW - it's also the same behavior as a v0 client that didn't 
implement anything but datum=1 (WGS84). The result is the same, I believe.

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 04:53:07 +0200

>>Some questions:
  >>
  >>a. Should a client implementation of RFC 3825bis be capable 
  >of handling 
  >>both v0 and v1 packets sent by a server?
  >
  >yes - because the server the client receives can be either 
  >from a v0 or v1 server.

It may, but it should not be required to. If the client does not like the location version provided by the server, it may ignore it and try to find another server which provides the location with the desired version.

- Gabor 

  >[mailto:[email-masked]] On Behalf Of ext James M. Polk
  >Sent: Tuesday, June 23, 2009 12:23 AM
  >[email-masked]; [email-masked]; [email-masked]
  >Cc: [email-masked]
  >Subject: Re: [Geopriv] Issue: version "negotiation"
  >
  >>"Certainly we shouldn't be encouraging people to try to 
  >send the old 
  >>encoding".
  >>
  >>Am I correct in saying that there is nothing in the 
  >DHCPDISCOVER packet 
  >>(or 11k location request, etc.) which provides the server with 
  >>information on the version of the client?
  >
  >>a. Should a client implementation of RFC 3825bis be capable 
  >of handling 
  >>both v0 and v1 packets sent by a server?
  >
  >yes - because the server the client receives can be either 
  >from a v0 or v1 server.
  >
  >>b. Should a server implementation of RFC 3825bis always set 
  >the version 
  >>number to 1?
  >
  >this depends on what it wants to convey to the client. If 
  >the server wants to deliver resolution bits, then a v0 
  >packet is sent to the client.
  >
  >If the server wants to send uncertainty bits, the servers 
  >sends v1 to the client.
  >
  >>c. Do we understand how existing v0 client implementations 
  >will behave 
  >>if they receive a v1 packet from a server?
  >
  >Part of 3825bis will add text to give guidance on the 
  >desired behavior for each scenario.
  >
  >James
  >
  >
  >

---

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

At 09:53 PM 6/23/2009, [email-masked] wrote:

>It may, but it should not be required to. If the client does not 
>like the location version provided by the server, it may ignore it

if this happens, then a client doesn't have location from the server, 
and has NO MEANS to tell the server it doesn't have location except 
to ask for Option 123 again, which will result in the server sending 
the same v1 again - which the client will reject.

Is this a solution?

I believe you are suggesting a configuration, not a protocol design.

>and try to find another server which provides the location with the 
>desired version.

but how *in DHCP*
#1 does a client learn which servers?
#2 does a client contact another server, given that it received the 
DHCP OFFER from the client sending out a broadcast message (asking 
for any server to answer)?

This is one of the shortfalls of DHCP, the client accepts the first 
answer from its broadcast, and doesn't move to the next OFFER (if 
there even is one).

---

From: <[email-masked]>
Date: Wed, 24 Jun 2009 21:42:06 +0200

Below inline: 

  >From: ext James M. Polk [mailto:[email-masked]] 
  >Sent: Wednesday, June 24, 2009 11:08 AM
  >To: Bajko Gabor (Nokia-CIC/MtView); 
  >[email-masked]; [email-masked]; 
  >Subject: RE: [Geopriv] Issue: version "negotiation"
  >
  >>It may, but it should not be required to. If the client 
  >does not like 
  >>the location version provided by the server, it may ignore it
  >
  >if this happens, then a client doesn't have location from 
  >the server, and has NO MEANS to tell the server it doesn't 
  >have location except to ask for Option 123 again, which will 
  >result in the server sending the same v1 again - which the 
  >client will reject.
  >
  >Is this a solution?

The client can make use of multiple protocols to acquire its location. If it chooses to use DHCP, but does not like the encoding of the location it receives, it can choose to use some other protocol, like HELD or SUPL, to get its location (possibly from a different LIS) in a format it likes.

  >#2 does a client contact another server, given that it 
  >received the DHCP OFFER from the client sending out a 
  >broadcast message (asking for any server to answer)?
  >
  >This is one of the shortfalls of DHCP, the client accepts 
  >the first answer from its broadcast, and doesn't move to the 
  >next OFFER (if there even is one).

Yes, it is difficult (if not impossible) in a DHCP-only LCP environment. But since LIS/LCP is a competivite market, if they want the location they provide to be used by clients, they better provide the location in a format in which clients expect it.

- Gabor

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 24 Jun 2009 18:55:03 -0500

in-line

At 02:42 PM 6/24/2009, [email-masked] wrote:
>The client can make use of multiple protocols to acquire its location.

this really isn't an answer, given that this discussion is all about 
that to put into 3825bis -- a DHCP document.

>If it chooses to use DHCP, but does not like the encoding of the 
>location it receives, it can choose to use some other protocol, like 
>HELD or SUPL, to get its location (possibly from a different LIS) in 
>a format it likes.

if a client uses HELD, why waste time with DHCP?

(I'm waiting for James and Martin to fall over.... ah, there they go)

I'll continue -- this isn't a catch all architecture discussion, this 
is how to make DHCP work, and DHCP only work.

>Yes, it is difficult (if not impossible) in a DHCP-only LCP 
>environment. But since LIS/LCP is a competivite market,

again - you are talking as if 3825bis needs to account for all these 
other LCPs... it doesn't. This document is how DHCP works -- and the 
WG was apparently unsatisfied with RFC 3825, so we are now modifying 
it to make is a viable solution. We can't say 'oh, gee... use another 
LCP if you want *that*...'. We need to define how *that* works in 
DHCP the best way it can.

>if they want the location they provide to be used by clients, they 
>better provide the location in a format in which clients expect it.

but your first reaction was to simply have the client ignore the 
OFFER, which isn't a solution at all.

---

From: <[email-masked]>
Date: Thu, 25 Jun 2009 05:58:53 +0200

>Sent: Wednesday, June 24, 2009 4:55 PM
  >this really isn't an answer, given that this discussion is 
  >all about that to put into 3825bis -- a DHCP document.
  >
  >>HELD or SUPL, to get its location (possibly from a 
  >different LIS) in a 
  >>format it likes.
  >

Right, this was one of the reasons why doing nothing but only deprecate 3825 was an alternative which the group considered. But this would have not been fair towards 802.11

  >I'll continue -- this isn't a catch all architecture 
  >discussion, this is how to make DHCP work, and DHCP only work.

Yes, I agree. But note, a client is not interested in the architecture, it is only interested in its location in the right format. If it doesn't get it using DHCP, will try other LIS, possibly using other LCP. We prefer to support multiple LCPs instead of an LCP with multiple location encodings.

  >again - you are talking as if 3825bis needs to account for 
  >all these other LCPs... it doesn't. 
  >This document is how 
  >DHCP works -- and the WG was apparently unsatisfied with RFC 
  >3825, so we are now modifying it to make is a viable 
  >solution.

I personally care about 3825 encoding just because it was adopted by 802.11, and the people there prefer to see a correction in the SDO where the original document was created, before making the corrections in  the 802.11 standard.

  > We can't say 'oh, gee... use another LCP if you 
  >want *that*...'. We need to define how *that* works in DHCP 
  >the best way it can.

Sure. But make that without requiring the clients to support both encodings, as that will not happen.
Putting the new encoding into a new dhcp option would be one way of doing it.

  >but your first reaction was to simply have the client ignore 
  >the OFFER, which isn't a solution at all.

For some clients it will be the right solution.

- Gabor

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 25 Jun 2009 01:07:09 -0500

>encodings, as that will not happen.

what you just said above is a far cry from "clients MUST NOT support v0"...

---

From: Marc Linsner <[email-masked]>
Date: Thu, 25 Jun 2009 08:17:38 -0400

Gabor,

An end host does not decide what LCP it uses to discover it's location, the
access network provider decides which LCP it supports.  Your assertion that
an end host can pick and chose which LCP it wants doesn't fly.  Hence, as
stated in the PhoneBCP, clients must support all LCPs whereas access
networks must support (at least) one LCP.  It's unclear (and unlikely, IMO)
whether access providers will support multiple LCPs.

-Marc-

On 6/24/09 11:58 PM, "[email-masked]" <[email-masked]> wrote:

> Right, this was one of the reasons why doing nothing but only deprecate 3825
> was an alternative which the group considered. But this would have not been
> fair towards 802.11
> 
> Yes, I agree. But note, a client is not interested in the architecture, it is
> only interested in its location in the right format. If it doesn't get it
> using DHCP, will try other LIS, possibly using other LCP. We prefer to support
> multiple LCPs instead of an LCP with multiple location encodings.
> 
> I personally care about 3825 encoding just because it was adopted by 802.11,
> and the people there prefer to see a correction in the SDO where the original
> document was created, before making the corrections in  the 802.11 standard.
>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 25 Jun 2009 09:21:30 -0700

>whether access providers will support multiple LCPs.

This design choice, that the client MUST support all LCPs (barring the LLDP-MED
exception carved out) is probably one of the most significant design choices
made by the group.  It's also one that I suspect is still not that well understood.
I continue to hear folks saying things like "supporting the L7 protocol alone
is enough; it's the common thread", without regard to the fact that the design
presumes that the operator could support DHCP alone and be conformant.

I'm not sure what else to do to bring that out, but I suspect we'll continue
to see questions about it for quite a while.
				Ted

---

From: <[email-masked]>
Date: Fri, 26 Jun 2009 06:54:33 +0200

Hi Mark,

I think you are focused too much on the emergency service case (where we expect some regulatory requirements), but geopriv's scope is wider than that. Even if the access network decides to support only one specific LCP, the clients already have a choice of access networks, thus the possibility to change access networks if that is required to fetch their location using the preferred LCP and in the preferred format, is there.

The requirement in the PhoneBCP is there just to address the less-and-less likely case when there is only one access network available at a given location and that access network supports one LCP. 
As an alternative, PhoneBCP could require the clients to support all access network types instead of supporting all LCPs ;)

>what you just said above is a far cry from "clients MUST NOT support v0"...

It's not a cry. Location of the client is a commodity, for which the clients are willing to pay. And some clients will not want location in certain formats, so a server providing location in an unpopular format will have a reduced customer base. If that format is coupled with an LCP, the LCP may become unpopular too. This luckily will not be a problem of the client, as there will be a choice of LCPs and location service providers anyway.

- Gabor

  >From: ext Marc Linsner [mailto:[email-masked]] 
  >Sent: Thursday, June 25, 2009 5:18 AM
  >To: Bajko Gabor (Nokia-CIC/MtView)
  >Cc: [email-masked]
  >An end host does not decide what LCP it uses to discover 
  >it's location, the access network provider decides which LCP 
  >it supports.  Your assertion that an end host can pick and 
  >chose which LCP it wants doesn't fly.  Hence, as stated in 
  >the PhoneBCP, clients must support all LCPs whereas access 
  >networks must support (at least) one LCP.  It's unclear (and 
  >unlikely, IMO) whether access providers will support multiple LCPs.
  >
  >-Marc-
  >
  >
  >>>>> To: Bajko Gabor (Nokia-CIC/MtView); [email-masked]; 
  >>>>> [email-masked]; [email-masked]; 
  >>>>>>> yes - because the server the client receives can be 
  >either from a 
  >>>>>>> v0 or v1 server.
  >>>>>> 
  >>>>> if this happens, then a client doesn't have location from the 
  >>>>> server, and has NO MEANS to tell the server it doesn't have 
  >>>>> location except to ask for Option 123 again, which will 
  >result in 
  >>>>> the server sending the same v1 again - which the client will 
  >>>>> reject.
  >>>>> 
  >>>>> Is this a solution?
  >>>> 
  >> Right, this was one of the reasons why doing nothing but only 
  >> deprecate 3825 was an alternative which the group 
  >considered. But this 
  >> would have not been fair towards 802.11
  >> 
  >discussion, this 
  >> Yes, I agree. But note, a client is not interested in the 
  >> architecture, it is only interested in its location in the right 
  >> format. If it doesn't get it using DHCP, will try other 
  >LIS, possibly 
  >> using other LCP. We prefer to support multiple LCPs 
  >instead of an LCP with multiple location encodings.
  >> 
  >received the 
  >>> other LCPs... it doesn't.
  >>> This document is how
  >>> DHCP works -- and the WG was apparently unsatisfied with 
  >RFC 3825, so 
  >>> we are now modifying it to make is a viable solution.
  >> 
  >> I personally care about 3825 encoding just because it was 
  >adopted by 
  >> 802.11, and the people there prefer to see a correction in the SDO 
  >> where the original document was created, before making the 
  >corrections in  the 802.11 standard.
  >> 
  >>> We can't say 'oh, gee... use another LCP if you want 
  >*that*...'. We 
  >>> need to define how *that* works in DHCP the best way it can.
  >> 
  >>>>>>> yes - because the server the client receives can be 
  >either from a 
  >>>>>>> v0 or v1 server.
  >>>>>>> 
  >>>>>>> this depends on what it wants to convey to the client. If the 
  >>>>>>> server wants to deliver resolution bits, then a v0 
  >packet is sent 
  >>>>>>> to the client.
  >>>>>>> 
  >>>>>>> If the server wants to send uncertainty bits, the 
  >servers sends 
  >>>>>>> v1 to the client.
  >>>>>>>

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 26 Jun 2009 16:53:33 -0400

In order to get interoperability when multiple protocols are available, you
have two choices: all entities implement all of them, or one end implements
all of them and the other implements at least one.  There isn't any other
way.  The PhoneBCP mechanism works for all applications.

Even if you add the possibility of multiple access networks, you still have
to implement all of the LCPs on the end device.

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.

What we find, however, is that the need to support the emergency case forces
both ends to implement what is needed for that.  After doing the emergency
case, everything else just works.

Brian

Brian

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of [email-masked]
> Sent: Friday, June 26, 2009 12:55 AM
> To: [email-masked]
> Cc: [email-masked]
> I think you are focused too much on the emergency service case (where
> we expect some regulatory requirements), but geopriv's scope is wider
> than that. Even if the access network decides to support only one
> specific LCP, the clients already have a choice of access networks,
> thus the possibility to change access networks if that is required to
> fetch their location using the preferred LCP and in the preferred
> format, is there.
> 
> The requirement in the PhoneBCP is there just to address the less-and-
> less likely case when there is only one access network available at a
> given location and that access network supports one LCP.
> As an alternative, PhoneBCP could require the clients to support all
> access network types instead of supporting all LCPs ;)
> 
> James Polk wrote:
> It's not a cry. Location of the client is a commodity, for which the
> clients are willing to pay. And some clients will not want location in
> certain formats, so a server providing location in an unpopular format
> will have a reduced customer base. If that format is coupled with an
> LCP, the LCP may become unpopular too. This luckily will not be a
> problem of the client, as there will be a choice of LCPs and location
> service providers anyway.
> 
> - Gabor
> 
>

---

From: <[email-masked]>
Date: Sat, 27 Jun 2009 02:22:00 +0200

Hi Brian,

  >From: ext Brian Rosen [mailto:[email-masked]]
  >Sent: Friday, June 26, 2009 1:54 PM
  >To: Bajko Gabor (Nokia-CIC/MtView); [email-masked]
  >Cc: [email-masked]
  >In order to get interoperability when multiple protocols are
  >available, you have two choices: all entities implement all
  >of them, or one end implements all of them and the other
  >implements at least one.  There isn't any other way.  The
  >PhoneBCP mechanism works for all applications.
  >
  >Even if you add the possibility of multiple access networks,
  >you still have to implement all of the LCPs on the end device.
  >
  >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

Right.

  >What we find, however, is that the need to support the
  >emergency case forces both ends to implement what is needed
  >for that.

The thing is, that currently regulators only mandate some of the fixed providers and all carriers operating in licenced bands to support emergency. In these cases, the carrier certifies a device before allowing it to connect to its network, thus it can force it to support a particular LCP or allow it to support none, if the carrier commits to assist the subscriber in placing the emergency call.

Therefore, currently there is no need to support emergency outside the regulatory domain, thus there is no need to implement LCPs not required by the carrier operating in the licenced bands. A client will of course support all LCPs which the vendor considers to be an added value, ie will allow the client to acquire its location and provide it to location hungry applications.

  >After doing the emergency case, everything else
  >just works.

Yes, emergency in generic terms is a superset of everything else and that comes with complexity. However, supporting emergency anywhere anytime is not a requirement of any government agency, thus vendors will not implement it just for the sake of generality, they will rather opt for supporting protocols which have added value to the customers. The market is the one which will make these decisions, not the standards.

- Gabor

  >[mailto:[email-masked]] On
  >> >>Sure. But make that without requiring the clients to
  >support both
  >> >>encodings, as that will not happen.
  >>
  >> >what you just said above is a far cry from "clients MUST
  >NOT support
  >> v0"...
  >>
  >[email-masked];
  >>   >> Sure. But make that without requiring the clients to
  >support both
  >>   >> encodings, as that will not happen.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Jun 2009 18:08:27 -0700

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

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 26 Jun 2009 20:40:33 -0500

At 08:08 PM 6/26/2009, Bernard Aboba wrote:
>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.

Bernard -- I think the key word you used above is 
"configuration".  Do we have a requirement that v0 and v1 can be 
configurable, and where is this configuration to occur?

I think the only place we cannot assume configuration is at the 3825 
unupgraded client. Therefore, the server within a domain has to be 
able to configure what the domain administrator wants to provide by the server.

I believe this is as far as the 3825bis doc can go, and not mandate 
v1 or v0 support any more than this.  This doc can RECOMMEND all day 
long, but I don't believe the bis doc can mandate anything on the 
v0/v1 issue. I could be wrong, but I believe v1 server/v0 client is 
what we have to allow for if we can.

James

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 26 Jun 2009 20:53:30 -0500

At 07:22 PM 6/26/2009, [email-masked] wrote:
>The thing is, that currently regulators only mandate some of the 
>fixed providers and all carriers operating in licenced bands to 
>support emergency. In these cases, the carrier certifies a device 
>before allowing it to connect to its network, thus it can force it 
>to support a particular LCP or allow it to support none, if the 
>carrier commits to assist the subscriber in placing the emergency call.

Gabor -- your whole argument is based on the assumption that there 
will be regulations proposed, written, passed, and enforced some time 
in the future -- since no one has written a single regulation 
mandating one LCP vs. another be implemented.

This assumption is something we cannot rely upon in the IETF.

That doesn't mean a Canadian PSAP might not write an RFP that only 
will allow 1 LCP, but this is never for the IETF to decide, or 
account for -- especially before any regulation is written.  The IETF 
knowingly should not build protocols that violate any laws (that do 
not have options not in violation) -- but something that enforced in 
Canada might perfectly all right in Europe. So which way do we design 
(IETF) protocols, for Canada or for Europe (or somewhere else)?

With regard to "...fixed providers and all carriers operating in 
licenced bands..." -- what does that have to do with the Internet?

>Therefore, currently there is no need to support emergency outside 
>the regulatory domain, thus there is no need to implement LCPs not 
>required by the carrier operating in the licenced bands. A client 
>will of course support all LCPs which the vendor considers to be an 
>added value, ie will allow the client to acquire its location and 
>provide it to location hungry applications.
>
>
>Yes, emergency in generic terms is a superset of everything else and 
>that comes with complexity. However, supporting emergency anywhere 
>anytime is not a requirement of any government agency, thus vendors 
>will not implement it just for the sake of generality, they will 
>rather opt for supporting protocols which have added value to the 
>customers. The market is the one which will make these decisions, 
>not the standards.

so let's all wait 5 years for vendors to implement proprietary 
solutions for different customers *BEFORE* we even start designing 
interoperable standards... at least that way we can choose what the 
market seems to be leaning towards, right? Though - then it becomes a 
case of which are the loudest customers who want their version to 
become _the_standard_ ...

gee, that'll be fun

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Jun 2009 19:29:34 -0700

> unupgraded client. 

Yes, because it is what it is (although the same could also be said of

a 3825 server). 

Question:  Is there a notion of configuration on an RFC 3825bis client? 

Although it might have preferences, it is not clear what it can do to

express them.  Saying a client supports RFC 3825bis would imply to me

that it can deal with a v1 response.  Wouldn't "backward compatibility" also imply

the ability of an RFC 3825bis client to handle a v0 response as well?   I'm trying 

to understand what the axes of "configuration" are for a client. 

> Therefore, the server within a domain has to be 

Sure.   Depending on what the population of clients is expected to be, the server

configuration might be different.  

> what we have to allow for if we can.

There are two distinct issues.  One is support (e.g. what an RFC 3825bis server

is capable of sending).  The other is what is used (e.g. what it is

configured to send).  If a server is only capable of sending a v0 response, 

wouldn't that make it an RFC 3825 server?  But just because an RFC 3825bis

server is capable of sending a v1 response doesn't mean that it is configured

to do so; that is an administrative choice. 

Given the potential downside of sending a v1 response to a v0 client

(even if it doesn't crash, it doesn't get location), where v0 clients are

expected, the ability to configure the RFC 3825bis server to send v0

responses seems like an important aspect of "backward compatibility".

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 26 Jun 2009 23:55:17 -0500

>Question:  Is there a notion of configuration on an RFC 3825bis client?

I think there needs to be in case the server is v0. We don't want it 
to puke on location (i.e., not accept Option 123) when the location 
is readable, just without uncertainty - which is better than no location.

>express them.

I don't believe it can express any.

>Saying a client supports RFC 3825bis would imply to me
>that it can deal with a v1 response.

that's a given I believe

>Wouldn't "backward compatibility" also imply
>the ability of an RFC 3825bis client to handle a v0 response as well?

that's what we're discussing, and I believe we ultimately have to say 
yes to this question, at least to the point of accepting the location 
values and datum, but possibly ignoring the resolution fields.

>  I'm trying

An operator may know they only have a v0 server, so they configure 
all their clients to be v0 clients. That's a configuration.

>configuration might be different.

The server could understand that certain circuitIDs are from v0 
clients, and the rest are from v1 clients - and tune its OFFER to the 
right asker.  This is probably more applicable on a per geographic 
boundary pov, like all those in city X, or building Y get v0, all 
other clients get v1 OFFERs

>wouldn't that make it an RFC 3825 server?

if it is only capable of 3825 OFFERs, then yes

>But just because an RFC 3825bis

this is one of the reasons why I don't believe we can MUST NOT send 
v0 responses, as wiki AI 10 says.

>responses seems like an important aspect of "backward compatibility".

I think this defines backwards compatibility, doesn't it?

James

---

From: Marc Linsner <[email-masked]>
Date: Sun, 28 Jun 2009 10:48:28 -0400

Gabor,

On 6/26/09 12:54 AM, "[email-masked]" <[email-masked]> wrote:

> Hi Mark,
> 
> I think you are focused too much on the emergency service case (where we
> expect some regulatory requirements), but geopriv's scope is wider than that.
> Even if the access network decides to support only one specific LCP, the
> clients already have a choice of access networks, thus the possibility to
> change access networks if that is required to fetch their location using the
> preferred LCP and in the preferred format, is there.
> 
> The requirement in the PhoneBCP is there just to address the less-and-less
> likely case when there is only one access network available at a given
> location and that access network supports one LCP.
> As an alternative, PhoneBCP could require the clients to support all access
> network types instead of supporting all LCPs ;)

I believe the requirement in PhoneBCP is to address real-world IP networks.
I also don't agree with your assertion of multiple access providers
available to most users.  This is certainly not true in the enterprise
space.  

The PhoneBCP requirement of hosts supporting all LCPs is an attempt to
support hosts moving from network to network.  As an example, we are trying
to allow for the same host to have network provided location available in
both office and home domains as many enterprise clients take their laptop
home with them.  Since this is example is obviously different network
environments, access providers will implement the LCP that best suits their
environment.  It's quite obvious that a network that doesn't support DHCP
won't offer RFC3285/4776.  It's also quite obvious a non-802 network will
not utilize LLDP-MED.  But, an 802 network using DHCP for host configuration
can utilize either choice, or choose HELD.  The arguments for a single LCP
are behind us.

So an end host with multiple access methods and one of which is an 802
network will need to support DHCP/HELD and imo, LLDP-MED.  The likelihood of
a host jumping from access network to access network to find their desired
LCP is a stretch, imo.

-Marc-

> It's not a cry. Location of the client is a commodity, for which the clients
> are willing to pay. And some clients will not want location in certain
> formats, so a server providing location in an unpopular format will have a
> reduced customer base. If that format is coupled with an LCP, the LCP may
> become unpopular too. This luckily will not be a problem of the client, as
> there will be a choice of LCPs and location service providers anyway.
> 
> - Gabor
> 
>

---

From: "Stark, Barbara" <[email-masked]>
Date: Sun, 28 Jun 2009 13:50:26 -0400

Umm, isn't phonebcp under ecrit, which is a working group dedicated to
the emergency services case? Since phonebcp is an ecrit document, why is
it relevant that geopriv's scope is broader? The geopriv LCPs are indeed
independent of emergency services. But if ecrit's phonebcp weren't
focused on their use for emergency services, I'd be very concerned.

If there's now to be a discussion of phonebcp, I think that would be
best done within ecrit and not geopriv. 
Barbara

> Behalf Of Marc Linsner
> Sent: Sunday, June 28, 2009 10:48 AM
> To: [email-masked]
> Cc: [email-masked]
> we
> access
> >> what you just said above is a far cry from "clients MUST NOT
support
> clients
> > reduced customer base. If that format is coupled with an LCP, the
LCP
> may

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA623

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 28 Jun 2009 19:36:39 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Saturday, 27 June 2009 11:08 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] Issue: version "negotiation"

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 28 Jun 2009 18:52:53 -0700

OK.  Strawman text to follow.   

Subject: RE: [Geopriv] Issue: version "negotiation"
Date: Sun, 28 Jun 2009 19:36:39 -0500
From: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
CC: [email-masked]

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: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba

Cc: [email-masked]

 

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

[mf2]