Subject: [Geopriv] Web-based DHCP location encoder

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Apr 2009 18:58:24 -0400

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 14 Apr 2009 19:31:24 -0500

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Wednesday, 15 April 2009 8:58 AM
> To: 'GEOPRIV'
> Subject: [Geopriv] Web-based DHCP location encoder
> 
> Hey all,
> 
> _______________________________________________
> 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: Richard Barnes <[email-masked]>
Date: Wed, 15 Apr 2009 11:42:50 -0400

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 15 Apr 2009 17:51:21 -0500

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: [email-masked] [mailto:[email-masked]] 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

--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.
>> deploying this stuff.  Please forward to anyone who might find this
------------------------------------------------------------------------
------------------------
> this email is prohibited.
------------------------------------------------------------------------
------------------------

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Apr 2009 19:05:36 -0400

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

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 15 Apr 2009 18:09:43 -0500

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:[email-masked]] 
Sent: Thursday, 16 April 2009 9:06 AM
To: Winterbottom, James
Cc: Thomson, Martin; GEOPRIV
Subject: Re: [Geopriv] Web-based DHCP location encoder

--Richard

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 15 Apr 2009 18:19:09 -0500

The following are mutually exclusive:

 - backward compatibility

 - clear version notification

Reusing the bits is not backwards compatibility.  To argue for a more "correct" approach is a red herring.

As James has stated, a non-bis-aware client is obliged to reject the entire option if it does not understand the datum.  For all it knows, the data might be Cartesian ECEF coordinates.  

If no change is made to datum, there is little impact.  The non-bis-aware client is getting a warped view from its interpretation of the resolution fields in any case.  At worst, the interpretation is shifted up to 50%.

--Martin

---

From: Richard Barnes <[email-masked]>
Date: Thu, 16 Apr 2009 09:55:17 -0400

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

---

From: [email-masked]
Date: Thu, 16 Apr 2009 17:23:50 +0100

> upgrade is pretty trivial.

I support this proposal, having mentioned it to various parties a few 
times over the last year, and I made exactly the same proposal myself 
on-list a couple of weeks ago ;-)

Ray

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

---

From: <[email-masked]>
Date: Thu, 16 Apr 2009 19:28:38 +0200

> If you set
  >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

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

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Thu, 16 Apr 2009 10:31:41 -0700

Gabor - "we are just in time".

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

Allan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Thursday, April 16, 2009 10:29 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Signaling versions in 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

  >>> to be any the wiser. In fact if you go around setting bit in
fields
  >> that
  >>> 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
  >>> So I am in opposition to providing a differentiator as you can't
do
  >> this
  >>> If you add the caveat that all flags being zero indicates the use
of
  >> the
  >>>> You'll note that the page clearly shows the two interpretations
of
  >> RFC
  >>>>> least) has always been figuring out how to encode and decode
them,
  >> so
  >>>>> deploying this stuff.  Please forward to anyone who might find
this
  >>>>> useful.
-----------------------------------------------------------------------
  >-
-----------------------------------------------------------------------
  >-
-----------------------------------------------------------------------
  >-
-----------------------------------------------------------------------
  >-
-----------------------------------------------------------------------
  >-------------------------
-----------------------------------------------------------------------
  >-------------------------
  >> [mf2]
  >>
  >>

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Thu, 16 Apr 2009 10:35:22 -0700

To be clear. We are NOT "just in time".

allan 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Allan Thomson (althomso)
Sent: Thursday, April 16, 2009 10:32 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Signaling versions in 3825bis

Allan 

-----Original Message-----

- gabor

fields
a
treat
do
of
of
them,
this

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 16 Apr 2009 16:30:00 -0700

The timeline of various IEEE 802.11 efforts is described here:
http://www.ieee802.org/11/Reports/802.11_Timelines.htm

As Gabor notes, WiFi Alliance has not yet created certification programs for
location (either IEEE 802.11k or 11y),
nor am I aware of any chipset vendors who have implemented this.  At present
the discussions are in the 
"Marketing Requirements" phase.

I've CC:'d the chair of IEEE 802.11v (Dorothy Stanley), who as I understand
it are looking to synchronize with 3825bis. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Allan Thomson (althomso)
Sent: Thursday, April 16, 2009 10:32 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [Geopriv] Signaling versions in 3825bis

Allan 

-----Original Message-----

- gabor

fields
a
treat
do
of
of
them,
this

---

From: "Allan Thomson (althomso)" <[email-masked]>
Date: Thu, 16 Apr 2009 17:18:59 -0700

Bernard - It is unclear that the PAR for TGv allows any changes to
11k/11y in this regard. The standards have been completed and anyone in
the market can implement to those standards. We can't stop them and we
can't certainly say with 100% certainty that no one has and no one will
implement them.

If we want to "fix" things we need to figure out what the agreed fix is
and what the appropriate mechanism to standardize the fix. We can't just
say "let's change 11k/11y". Its too late for those amendments. 

Being a participant in TGv I can say that the only person that has
suggested 3825bis in that forum is Gabor. So it is an incorrect
statement to say that "TGv" is looking to synchronize with 3825bis. 

There is a desire to leverage the work in the IETF geopriv group where
it makes sense. We have tried very hard to avoid duplicating work that
has already taken place in the geopriv group.

However, I would suggest that before the TGv group in IEEE adopts or
refers to any specification from the geopriv group, there needs to be a
clear consensus in IETG geopriv group on a particular specification. 

I don't believe there is such consensus on 3825bis from what I've
observed from my colleagues and watching this reflector.

Allan

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009 4:30 PM
To: Allan Thomson (althomso); [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Geopriv] Signaling versions in 3825bis

As Gabor notes, WiFi Alliance has not yet created certification programs
for location (either IEEE 802.11k or 11y), nor am I aware of any chipset
vendors who have implemented this.  At present the discussions are in
the "Marketing Requirements" phase.

I've CC:'d the chair of IEEE 802.11v (Dorothy Stanley), who as I
understand it are looking to synchronize with 3825bis. 

-----Original Message-----

Allan 

-----Original Message-----

- gabor

fields
a
treat
do
of
of
them,
this

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 16 Apr 2009 20:57:47 -0500

Interpretation of "uncertainty" in 3825 is demonstrably broken.  I fail to see how a misinterpretation of these fields is going to result in a worse situation for a pre-bis implementation.  I can see how forcing them to reject the location information would be bad.

I actually see the small deployed base as good justification for the opposite of what you are arguing.  

You know, I almost feel sorry for 802.11, because the time we spend dithering (a few years now, in fact) only makes it worse for them.

More inline...

> Sent: Thursday, 16 April 2009 11:55 PM
> To: Winterbottom, James
> Subject: Signaling versions in 3825bis
> 
> James,
> 

You're arguing for implementation that is aware of the changes in the bis.  Did you think about that?
 
> especially during basketball season!

50%, 75%, no matter, neither location is significantly more useful than the other.  Neither changes your actual location - the one that you will have to verbally give to the PSAP operator because no emergency responder is ever going to find you based on such a big change.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Apr 2009 20:33:16 -0700

While "anyone can implement" these standards, are there any station chipset vendors that have implemented 11k or 11y location, or any station products that support it?  

The February 2009 WFA Voice Enterprise bakeoff only covered a subset of 11k functionality such as the Neighbor Report, but not location or radio resource management functionality.   Even though IEEE 802.11k and 11r were published in June 2008, we're still waiting for shipping implementations of either. 

Nowadays, major chipset vendors are largely focused on the consumer market and the mainstream Wifi logo certification which caters to that market.  Optional certifications (such as Voice Personal or Voice Enterprise) garner considerably less interest, and as a result, getting enough implementations to complete a bakeoff and start a certification program can encounter considerable delays.   At this point, location is still in the MRD stage, right?  

That said, I'm not arguing for yet another decade-long IETF death march that only seems to yield meaningful deployment after commercial vendors have given up hope.  Just sayin' that this particular horse isn't fast out of the gate by IEEE 802 standards.

> Date: Thu, 16 Apr 2009 17:18:59 -0700
> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked]

---

From: "Thomson, Martin" <[email-masked]>
Date: Fri, 17 Apr 2009 00:15:53 -0500

In the interests of closing this issue, Richard and I have just discussed this issue at some length.

I will endeavour to be value-neutral in this email.  I will follow up with my own conclusions some time later.

Option 1: Version tag.  A tag is included will cause clients that don't understand the new encoding to reject the message.  Regardless of how this is selected, the point is to force this rejection - to prevent the client from interpreting the data incorrectly.  Currently, this would involve adding a new datum that clients wouldn't understand, forcing them to reject the data.

Option 2: No version tag.  The alternative is to avoid the version tag and risk having the data misinterpreted.

First, the truth tables.

There are two tables, showing all combinations of 3825 (-) and 3825bis (bis) for when a version tag is included and when one is not.

Client	Server	Result
-           -        OK - not possible
-           bis      reject - client rejects option
bis         -        OK - client can interpret
bis         bis      OK

Client	Server	Result
-           -        OK
-           bis      wrong interpretation of uncertainty
bis         -        wrong interpretation of uncertainty
bis         bis      OK

Both options have negative consequences.  Therefore, we need a way to arbitrate.

Let's try a little old-fashioned risk analysis.  Cost of each approach is the probability of the negative event multiplied by the cost of the event.  I'll use symbols - you can assign your own values and make your own judgement based on your set of values.

  Pc = Probability of having an old client.
  Ps = Probability of having an old server.
  Pi = Probability that resolution/uncertainty is used and relied upon by the client.
  Cr = Cost of rejecting the option.
  Cw = Cost of misinterpreting the uncertainty.

Therefore risk analysis assigns the following costs:

  Version tag = Pc * Cr
  No version tag = (Pc + Ps) * Pi * Cw

Ultimately, assigning values to these is going to be somewhat subjective, but here are the arguments and conclusions we came to:

  (Pc << 1) The number of actual deployments of implementations that use the 3825 is known to be quite small... some say non-existent.

  (Cr > Cw) In general, it's worse to have nothing than to be wrong(ish).  As already discussed, a shift (up to 50% in distance, 75% in area) in uncertainty might not be a problem.  On the other hand, rejecting the entire option outright could prevent use of location information at all.

  (Ps < Pc) Probably.  That is, it seems likely that a server is upgraded ahead of all its clients.  There are exceptions.

Even though it's not a good basis for design, the emergency issue might be important to you.  Current accepted wisdom states that wrong location is better than no location at all as long as it isn't too wrong.  You might to assign values such that (Cr >> Cw)...  An error in interpreting uncertainty is not good, but at least you get a call through.
	
So, examples:

If I assign: Ps = Pc = 5%, Pi = 80%, Cr = 1.2, Cw = 1
  A version tag is considered a good choice at a cost of 0.06 over a cost of 0.08 for no version tag.

Or I could assign: Ps = 5%, Pc = 3%, Pi = 60%, Cr = 1.5, Cw = 1
  No version tag is the conclusion at a cost of 0.048 over a cost of a tag at 0.075.

Don't let my examples influence your own evaluation.  Choose your own numbers.  I just picked a set of numbers that worked for either position.

--Martin

---

From: "Dorothy Stanley" <[email-masked]>
Date: Fri, 17 Apr 2009 15:53:07 -0700

Bernard, all,

What is the status of the RFC3825-bis document, e.g. last call
completed? in IESG review? and
when is publication expected?

As input to IEEE 802.11, so that  TGv (or other groups) can determine
the next logistical steps in IEEE 802.11

to align with IETF recommendations.

Thanks,

Dorothy

________________________________

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Thursday, April 16, 2009 8:33 PM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; Dorothy Stanley; [email-masked]
Subject: RE: [Geopriv] Signaling versions in 3825bis

While "anyone can implement" these standards, are there any station
chipset vendors that have implemented 11k or 11y location, or any
station products that support it?  

The February 2009 WFA Voice Enterprise bakeoff only covered a subset of
11k functionality such as the Neighbor Report, but not location or radio
resource management functionality.   Even though IEEE 802.11k and 11r
were published in June 2008, we're still waiting for shipping
implementations of either. 

Nowadays, major chipset vendors are largely focused on the consumer
market and the mainstream Wifi logo certification which caters to that
market.  Optional certifications (such as Voice Personal or Voice
Enterprise) garner considerably less interest, and as a result, getting
enough implementations to complete a bakeoff and start a certification
program can encounter considerable delays.   At this point, location is
still in the MRD stage, right?  

That said, I'm not arguing for yet another decade-long IETF death march
that only seems to yield meaningful deployment after commercial vendors
have given up hope.  Just sayin' that this particular horse isn't fast
out of the gate by IEEE 802 standards.

<http://im.live.com/Messenger/IM/Home/?source=EML_WLHM_GreaterGood>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 20 Apr 2009 08:22:42 +0200

It is an author draft still under discussion for work to be charted in IETF - i.e. it has progressed to none of the milestones you mention.

They are still doing the list consensus calls based on the report of IETF#74

Martin Thomson describes 3825bis

Chairs: Do we want to fix 3825 or create a new doc with shapes and a new

way to define point

MT: Fix only, use a reference if you need more

JPo: Replace, fix is okay

HS: Second system syndrome. Don't want a third format between binary

and XML (by reference). For 3825, just remove the resolution field.

Show of hands for fixing 3825: strongly in favor

Show of hands for any new format: 2 for, 10 against

I haven't yet seen anyone declare a consensus.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dorothy Stanley
Sent: Friday, April 17, 2009 11:53 PM
To: Bernard Aboba; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Geopriv] Signaling versions in 3825bis

Bernard, all,

What is the status of the RFC3825-bis document, e.g. last call completed? in IESG review? and
when is publication expected?

As input to IEEE 802.11, so that  TGv (or other groups) can determine the next logistical steps in IEEE 802.11
to align with IETF recommendations.

Thanks,

Dorothy

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 20 Apr 2009 02:19:20 -0500

This is almost certainly too much detail...

On wrong answers, here are a few things to consider.
	
At worst, the result is off by 50% in either X or Y.  This leads to a probability of the actual location being outside the misinterpreted area of uncertainty being 7/16, assuming rectangular distribution and 100% confidence.

However, this assumes that the intended "uncertainty" was of the size that the alternative encoding method represented.  Due to the nature of the encoding, the size is bound to powers of 2.  That means that if the uncertainty is increased from just above one power of 2 to the next larger value, the area is close to double the size of the original area.  The potential error approaches zero.

Thus, if you like, add a probability factor to the option with no version tag that accounts for the probability that the answer is truly "wrong" of less than 0.466(*).  Of course, this doesn't account for the error in interpreting the intent of the entity encoding the option.

My opinion has only been more strongly confirmed by this analysis.

--Martin

* 7/16*0.95 + 0.05, which can be halved if you allow for uncertainty of evenly distributed size being input.

> Behalf Of Thomson, Martin
> Sent: Friday, 17 April 2009 3:16 PM
> To: [email-masked]
> Cc: [email-masked]
> Option 1: Version tag.  A tag is included will cause clients that don't
> understand the new encoding to reject the message.  Regardless of how
> this is selected, the point is to force this rejection - to prevent the
> client from interpreting the data incorrectly.  Currently, this would
> involve adding a new datum that clients wouldn't understand, forcing
> them to reject the data.
> 
> There are two tables, showing all combinations of 3825 (-) and 3825bis
> (bis) for when a version tag is included and when one is not.
> 
> 
> Client	Server	Result
> -           -        OK - not possible
> Let's try a little old-fashioned risk analysis.  Cost of each approach
> is the probability of the negative event multiplied by the cost of the
> event.  I'll use symbols - you can assign your own values and make your
> own judgement based on your set of values.
> 
> Ultimately, assigning values to these is going to be somewhat
> subjective, but here are the arguments and conclusions we came to:
> 
>   (Pc << 1) The number of actual deployments of implementations that
> use the 3825 is known to be quite small... some say non-existent.
> 
>   (Cr > Cw) In general, it's worse to have nothing than to be
> wrong(ish).  As already discussed, a shift (up to 50% in distance, 75%
> in area) in uncertainty might not be a problem.  On the other hand,
> rejecting the entire option outright could prevent use of location
> information at all.
> 
>   (Ps < Pc) Probably.  That is, it seems likely that a server is
> upgraded ahead of all its clients.  There are exceptions.
> 
> Even though it's not a good basis for design, the emergency issue might
> be important to you.  Current accepted wisdom states that wrong
> location is better than no location at all as long as it isn't too
> wrong.  You might to assign values such that (Cr >> Cw)...  An error in
> interpreting uncertainty is not good, but at least you get a call
> through.
> 
> So, examples:
> 
> Don't let my examples influence your own evaluation.  Choose your own
> numbers.  I just picked a set of numbers that worked for either
> position.
> 
> --Martin
> 
>