Re: [Geopriv] Signaling versions in 3825bis

From: Allan Thomson (althomso) ^lt;althomso@cisco.com>
Date: Thu Apr 16 2009 - 13:31:41 EDT

Gabor - "we are just in time".

Both 11k and 11y (both use 3825) are now part of the base standard.

Allan

-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
Behalf Of Gabor.Bajko@nokia.com
Sent: Thursday, April 16, 2009 10:29 AM
To: rbarnes@bbn.com; James.Winterbottom@andrew.com
Cc: geopriv@ietf.org; Martin.Thomson@andrew.com
Subject: Re: [Geopriv] Signaling versions in 3825bis

> If you set
>(lat, lon, laRes, loRes) = (35.94239, -78.99426, 12, 13)
>then the 3825 encoding push you in Durham, NC, while the 3825bis
>encoding puts you in Chapel Hill.

This is why rfc3825 has to be deprecated and rfc3825bis decoding taken
into use. There should not be two different (valid) ways of decoding the
information.

The rfc3825 encoding is imported into 802.11, but it is not implemented
yet as it has not been certified yet. I think we are just in time to
prevent the spread of rfc3825 encoding usage.

- gabor

>-----Original Message-----
>From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
>Behalf Of ext Richard Barnes
>Sent: Thursday, April 16, 2009 6:55 AM
>To: Winterbottom, James
>Cc: GEOPRIV; Thomson, Martin
>Subject: [Geopriv] Signaling versions in 3825bis
>
>James,
>
>I assume the case you're worried about is the emergency services
case.
>This is not really an issue IMO, since the emergency calling clients
can
>make a special case that forces an option in an unknown datum to be
>interpreted. In non-emergency cases, it is correct behavior for the
>client to reject an option that it cannot interpret correctly.
>
>Martin's point that you can be at most 50% wrong is a little bit
>misleading as well, since (1) you're actually wrong by 75% in area
>terms, 50% in each dimension, and (2) that 75% can be really large if
>the resolution/uncertainty values aren't terribly small. If you set
>(lat, lon, laRes, loRes) = (35.94239, -78.99426, 12, 13)
>then the 3825 encoding push you in Durham, NC, while the 3825bis
>encoding puts you in Chapel Hill. This can be an important
distinction,
>especially during basketball season!
>
>Finally, as Hannes has pointed out, it's not like there's a huge
>deployed base of 3825-compliant clients out there, and the change to
>upgrade is pretty trivial.
>
>--Richard
>
>
>
>
>Winterbottom, James wrote:
>> To be clear though, that in this case the Target will likely get no
>> location at all as I think it is unlikely that any access network
will
>> deploy more than one LCP. The result of this is not good. Hence my
>> suggestion.
>>
>> Cheers
>> James
>>
>>
>>
>> -----Original Message-----
>> From: Richard Barnes [mailto:rbarnes@bbn.com]
>> Sent: Thursday, 16 April 2009 9:06 AM
>> To: Winterbottom, James
>> Cc: Thomson, Martin; GEOPRIV
>> Subject: Re: [Geopriv] Web-based DHCP location encoder
>>
>> It is correct behavior for an old client to reject an option
encoded
>> with the new semantic -- otherwise it will get interpret the option
>> incorrectly. So providing a switch doesn't break backward
>compatibility
>>
>> (the way you do encode the RFC 3825 semantic will be the same,
>> bit-for-bit, as before), but rather provides an orderly transition.
>>
>> --Richard
>>
>>
>>
>> Winterbottom, James wrote:
>>> I am not so sure that I understand how this will help.
>>> If the data is encoded using the BIS format then no old client is
>> going
>>> to be any the wiser. In fact if you go around setting bit in
fields
>> that
>>> it doesn't understand, it is just as likely to go around rejecting
the
>>> option as containing an error.
>>>
>>> My proposal would be that we don't do any indication. If you have
a
>> BIS
>>> client, great, you get a non-broken view of the world, and you
treat
>> all
>>> encodings as BIS. If you don't then if you get a BIS encoded
option,
>>> then you are not really any worse off than if it wasn't encoded
that
>>> way.
>>>
>>> So I am in opposition to providing a differentiator as you can't
do
>> this
>>> without breaking backward compatibility.
>>>
>>> Cheers
>>> James
>>>
>>>
>>> -----Original Message-----
>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
On
>>> Behalf Of Richard Barnes
>>> Sent: Thursday, 16 April 2009 1:43 AM
>>> To: Thomson, Martin
>>> Cc: GEOPRIV
>>> Subject: Re: [Geopriv] Web-based DHCP location encoder
>>>
>>> Count me in with the folks who think there needs to be some sort
of
>>> indicator as to which interpretation is being communicated.
Attaching
>>
>>> two different semantics to the exactly the same set of bits is the
>>> definition of non-interoperability.
>>>
>>> Looking at the 3825 format, it seems that the "datum" field is the
>> only
>>> one where there's any chance of accommodating this indicator.
>> Defining
>>> a single new datum is one way of doing it. Another way might be
to
>>> split the field half: A 4-bit datum field (do we need more than 31
>>> data?) and 4 bits of flags (one for this, and three for later
use).
>>>
>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
>>> | Datum | ---> | Flags | Datum |
>>> +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
>>>
>>> If you add the caveat that all flags being zero indicates the use
of
>> the
>>> 3825 encoding, this remains bitwise backward-compatible with 3825
>> (since
>>> a 3825 server will set all flags to zero).
>>>
>>> --Richard
>>>
>>>
>>>
>>> Thomson, Martin wrote:
>>>> You'll note that the page clearly shows the two interpretations
of
>> RFC
>>> 3825. If you zoom to show the area described by the option and
toggle
>>> the 3825bis checkbox, you'll see how these differ. In particular,
>> note
>>> the difference when the point is near the edge of the box drawn
using
>>> the (not bis) 3825 interpretation.
>>>> Richard: The encodings are the same, only the interpretation
differs.
>>>> s/Alternate encoding/Alternative interpretation/
>>>>
>>>>> -----Original Message-----
>>>>> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
On
>>>>> Behalf Of Richard Barnes
>>>>> Sent: Wednesday, 15 April 2009 8:58 AM
>>>>> To: 'GEOPRIV'
>>>>> Subject: [Geopriv] Web-based DHCP location encoder
>>>>>
>>>>> Hey all,
>>>>>
>>>>> FYI: The daunting thing about the DHCP location options (for me
at
>>>>> least) has always been figuring out how to encode and decode
them,
>> so
>>>>> with some help from the loc-imp list, I've written a web-based
>>> encoder
>>>>> for the DHCP location options (RFC 3825 and 4776):
>>>>>
>>>>> <http://geopriv.dreamhosters.com/dhcloc/>
>>>>>
>>>>> (Actually, the decoding logic is there too, in the Javascript
>>> objects,
>>>>> but there's no GUI for it now.)
>>>>>
>>>>> Hopefully, this can be at least a basic tool to ease people into
>>>>> deploying this stuff. Please forward to anyone who might find
this
>>>>> useful.
>>>>>
>>>>> Cheers,
>>>>> --Richard
>>>>> _______________________________________________
>>>>> Geopriv mailing list
>>>>> Geopriv@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/geopriv
>>
-----------------------------------------------------------------------
>-
>>> ------------------------
>>>> This message is for the designated recipient only and may
>>>> contain privileged, proprietary, or otherwise private
information.
>>>> If you have received it in error, please notify the sender
>>>> immediately and delete the original. Any unauthorized use of
>>>> this email is prohibited.
>>>>
>>
-----------------------------------------------------------------------
>-
>>> ------------------------
>>>> [mf2]
>>> _______________________________________________
>>> Geopriv mailing list
>>> Geopriv@ietf.org
>>> https://www.ietf.org/mailman/listinfo/geopriv
>>>
>>>
>>
-----------------------------------------------------------------------
>-
>> ------------------------
>>> This message is for the designated recipient only and may
>>> contain privileged, proprietary, or otherwise private information.
>>> If you have received it in error, please notify the sender
>>> immediately and delete the original. Any unauthorized use of
>>> this email is prohibited.
>>>
>>
-----------------------------------------------------------------------
>-
>> ------------------------
>>> [mf2]
>>>
>>>
>>
>>
-----------------------------------------------------------------------
>-------------------------
>> This message is for the designated recipient only and may
>> contain privileged, proprietary, or otherwise private information.
>> If you have received it in error, please notify the sender
>> immediately and delete the original. Any unauthorized use of
>> this email is prohibited.
>>
-----------------------------------------------------------------------
>-------------------------
>> [mf2]
>>
>>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org
>https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
Received on Thu, 16 Apr 2009 10:31:41 -0700

This archive was generated by hypermail 2.1.8 : Thu Apr 16 2009 - 13:33:29 EDT