Subject: [Geopriv] Short (5 page) ID to "update" RFC 3825

From: "James M. Polk" <[email-masked]>
Date: Thu, 23 Apr 2009 15:51:41 -0500

Geopriv

Here's a short ID looking to simplify the RFC 3825 effort.

http://www.ietf.org/internet-drafts/draft-polk-geopriv-3825-update-00.txt

- this ID creates the "switch" the chairs were looking for indicating 
when the resolution fields should remain resolution values, or when 
they become confidence and uncertainty values. This is done by adding 
an Option 123 version field, which dictates one version has 
resolution fields, and another has confidence/uncertainty 
fields.  This mechanism is backwards compatible, which is another 
goal from the chairs.

- this ID modifies the existing 8-bit datum field into 3 separate 
fields (datum, version, and reserved). Reading the ID will give the 
story why this proposal does this.

- this ID aligns with IEEE (which appears to be a goal)

- this ID directs the reader towards how to define confidence and uncertainty

- this ID tells the reader of RFC 3825 to not bother with the 
appendix when there are no resolution fields, thus reducing confusion.

- this ID does not add a v6 Option, but could with a little more text 
(that's fairly straightforward to write) -- if WG consensus wants this added

Here's the abstract:

This document updates RFC 3825 (Dynamic Host Configuration Protocol
Option for Coordinate-based Location Configuration Information) to
allow versioning, and proposes changes that enable the ability to
express confidence and uncertainty values as an alternative to
expressing bits of resolution.

Comments are welcome

James, Marc & Allan

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 23 Apr 2009 17:57:08 -0500

This is certainly a marked improvement over draft-ietf-geopriv-binary-lci.  3825bis wouldn't ever have existed if this was the form that binary-lci took.  But, that was over 2 years ago.  In that time we've had two lots of agreement to "fix" the problem, one failed attempt, and now a slew of drafts.

Why can't we focus all this energy on something important?  There are milestones that are long overdue that we continue to ignore because we are all caught up on a mouldy old issue.

--

Now that I'm de-ranted, there are problems with this approach.

Read my risk analysis email [1] on the trade-off between versioning and not.  My conclusion based on that analysis is that the addition of a version field is not a good idea.  Versioning forces rejection of an option rather than allowing for the chance of a minor misinterpretation.  I invite further discussion on the issue.

Please don't assume authority just because a chair expresses support for an idea.  If Richard wants to call consensus on the issue, then I'll shut up.  Until then, I'd call the issue open.

I also observe that the bit order in this draft is inverted.  I almost thought that this had gotten the datum field upside down until I saw the example.  10000010 is not 65, 01000001 is.

Ta,
Martin

[1] <http://www.ietf.org/mail-archive/web/geopriv/current/msg07099.html>

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of James M. Polk
> Sent: Friday, 24 April 2009 6:52 AM
> To: [email-masked]
> Subject: [Geopriv] Short (5 page) ID to "update" RFC 3825
> 
> Geopriv
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> 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]

---

From: [email-masked]
Date: Fri, 24 Apr 2009 08:14:03 +0100

> Read my risk analysis email [1] on the trade-off between versioning 
> and not.  My conclusion based on that analysis is that the addition 
> of a version field is not a good idea.  Versioning forces rejection 
> of an option rather than allowing for the chance of a minor 
> misinterpretation.  I invite further discussion on the issue.

Notwithstanding that the datum most commonly in use (WGS84) is already 
covered, IMHO the same arguments would appear to prevent us from _ever_ 
adding new datums to RFC 3825.  e.g. "we can't add a new datum because the 
old client base doesn't know how to interpret it".

Ray

---

From: [email-masked]
Date: Fri, 24 Apr 2009 08:19:06 +0100

> (that's fairly straightforward to write) -- if WG consensus wants this 
added

Looks good to me, and it's interesting to note that for .11y IEEE have 
already decided they only need a 3 bit datum field.

One thing though - is there any reason we can't call RFC 3825 "version 0", 
so that the bit representation and the "human readable" version number 
don't have an ongoing off-by-one discrepancy?

cheers,

Ray

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 24 Apr 2009 06:51:11 -0400

Ray,

I think the idea has always been to have 3825 be version 0 (if there's 
going to be a version number), so that the 3825 encoding emerges as a 
special case of the version-numbered encoding.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Fri, 24 Apr 2009 06:53:13 -0400

> Please don't assume authority just because a chair expresses support
> for an idea.  If Richard wants to call consensus on the issue, then
> I'll shut up.  Until then, I'd call the issue open.

This is correct.  I did not intend at any point to imply that there was 
WG consensus on that issue (and I don't think Alissa has commented on 
it).  It's just my personal opinion that a version field is a good idea.

--Richard

> 
> I also observe that the bit order in this draft is inverted.  I
> almost thought that this had gotten the datum field upside down until
> I saw the example.  10000010 is not 65, 01000001 is.
> 
> Ta, Martin
> 
> [1]
> <http://www.ietf.org/mail-archive/web/geopriv/current/msg07099.html>
> 
> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of James M. Polk Sent:
>> Friday, 24 April 2009 6:52 AM To: [email-masked] Subject:
>> [Geopriv] Short (5 page) ID to "update" RFC 3825
>> 
>> Geopriv
>> 
>> - this ID creates the "switch" the chairs were looking for
>> indicating when the resolution fields should remain resolution
>> values, or when they become confidence and uncertainty values. This
>> is done by adding an Option 123 version field, which dictates one
>> version has resolution fields, and another has
>> confidence/uncertainty fields.  This mechanism is backwards
>> compatible, which is another goal from the chairs.
>> 
>> - this ID does not add a v6 Option, but could with a little more
>> text (that's fairly straightforward to write) -- if WG consensus
>> wants this added
>> 
>> Here's the abstract:
>> 
>> _______________________________________________ Geopriv mailing
>> list [email-masked] 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 [email-masked]

---

From: [email-masked]
Date: Fri, 24 Apr 2009 12:54:52 +0100

> special case of the version-numbered encoding.

The draft says otherwise:

"This leaves 4 possible versions, where version 1 is defined by RFC 3825. 
Version 2 is defined here"

except that "Version 1" has the bit pattern "00", and Version 2 has the 
bit pattern (in LSB first order) of "10", or 1 in decimal.

Ray

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 24 Apr 2009 12:51:23 -0500

>old client base doesn't know how to interpret it".

Ray -- this is true for every IETF protocol that uses anything that 
isn't in the core spec. That's why there is an IANA registry, for 
implementers to see what's available (and to prevent collisions ;-)

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 24 Apr 2009 12:53:38 -0500

At 02:19 AM 4/24/2009, [email-masked] wrote:
>Looks good to me,

thanks

>  and it's interesting to note that for .11y IEEE have

we didn't learn this fact until examining .11y for this ID

>don't have an ongoing off-by-one discrepancy?

we only made this change in the last pre-submission version.

WG consensus would have us change it back (easily)

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 24 Apr 2009 12:54:24 -0500

At 05:51 AM 4/24/2009, Richard Barnes wrote:
>Ray,
>
>I think the idea has always been to have 3825 be version 0 (if 
>there's going to be a version number), so that the 3825 encoding 
>emerges as a special case of the version-numbered encoding.

Richard

I'm ok with that change

>>>values, or when they become confidence and uncertainty values. 
>>>This is done by adding an Option 123 version field, which dictates 
>>>one version has resolution fields, and another has 
>>>fields (datum, version, and reserved). Reading the ID will give 
>>>the story why this proposal does this.
>>>
>>>text (that's fairly straightforward to write) -- if WG consensus wants this
>>added
>>Looks good to me, and it's interesting to note that for .11y IEEE 
>>have already decided they only need a 3 bit datum field.
>>One thing though - is there any reason we can't call RFC 3825 
>>"version 0", so that the bit representation and the "human 
>>readable" version number don't have an ongoing off-by-one discrepancy?
>>cheers,
>>Ray

---

From: "James M. Polk" <[email-masked]>
Date: Fri, 24 Apr 2009 12:56:46 -0500

>bit pattern (in LSB first order) of "10", or 1 in decimal.

you are correct.

Is that match really that important?

If so, we can change it.

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 26 Apr 2009 18:39:30 -0500

Indeed it would prevent use of new datums.  But then WGS84 is adequate.  If the world starts using a new datum in future, then it really isn't that bad to have to convert.  Unless things get a whole lot stranger, interplanetary datums are the only case I can think of where WGS84 wont convert easily.  But then, I'd suspect that DHCP LCI isn't going to be the protocol container of choice anyhow.

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, 24 April 2009 5:14 PM
> To: Thomson, Martin
> Cc: [email-masked]; [email-masked]; James M. Polk
> Subject: Re: [Geopriv] Short (5 page) ID to "update" RFC 3825
>