Subject: [Geopriv] [geopriv] rfc3825bis #44 (new): Jari's DISCUSS

From: "geopriv issue tracker" <[email-masked]>
Date: Sat, 04 Dec 2010 20:38:18 -0000

#44: Jari's DISCUSS

 I think the backwards compatibility design is wrong. If there's really
 implementations of the old RFC (are there?) the right thing to do would
 be to separate code points at the DHCP level so that peaceful co-existence
 of new and old clients can happen.

 Also, the normalization process pointed to by Ari's review (below) seems
 suspect. Garbage in, garbage out. If the DHCP server cannot be trusted
 to follow this specific, a number in the wrong range is equally likely
 just bad data. Silently ignoring such options might be the better choice
 here. There are obvious downsides to incorrect determination of location.

 Comment (2010-12-02)

 Ari Keränen reviewed this specification and he had a few comments:

 The abstract should state that this document obsoletes RFC 3825 and the
 intro should explain why it's done (as described in the I-D checklist).

 However, instead of obsoleting 3825, wouldn't it make more sense to have
 a new IPv4 DHCP option for this new version given that the new encoding
 is not compatible with the old one and re-using the same value seems to
 cause a lot of problems (as described in section 2.2.1)? Or otherwise it
 would be good idea to mention the reason (preserving DHCP codes?) for
 not doing so.

 2.3.  Latitude and Longitude Fields

     Latitude values encoded by the DHCP server MUST be constrained to the
     range from -90 to +90 degrees.  Location consumers MUST be prepared
     to normalize values outside this range.  Values outside the range are
     normalized by clamping [...]

 If the values MUST be within those boundaries, doesn't it mean that a
 value that is out of the range is somewhat likely completely wrong (due
 to a broken implementation) and thus it would make sense to ignore it
 rather than try to normalize the value and make it appear as if it was
 valid? I'm not sure if I'd like to be liberal in what I accept when it
 comes to information that could literally be a matter of life and death.

-- 
---------------------------------------+------------------------------------
 Reporter:  bernard_aboba@…            |       Owner:  bernard_aboba@…           
     Type:  defect                     |      Status:  new                       
 Priority:  blocker                    |   Milestone:  draft-ietf-geopriv-3825bis
Component:  rfc3825bis                 |     Version:  1.0                       
 Severity:  Submitted WG Document      |    Keywords:                            
---------------------------------------+------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/geopriv/trac/ticket/44>
geopriv <http://tools.ietf.org/geopriv/>