Skip to main content

Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information
RFC 6225

Yes

(Robert Sparks)

No Objection

(Adrian Farrel)
(Alexey Melnikov)
(Dan Romascanu)
(Gonzalo Camarillo)
(Peter Saint-Andre)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Tim Polk)

Note: This ballot was opened for revision 17 and is now closed.

Robert Sparks Former IESG member
(was Discuss, Yes) Yes
Yes ()

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection ()

                            
Alexey Melnikov Former IESG member
No Objection
No Objection ()

                            
Dan Romascanu Former IESG member
No Objection
No Objection ()

                            
David Harrington Former IESG member
(was Discuss) No Objection
No Objection (2010-11-30)
1) section 1, paragraph 4 says "The DHCP server could correlate the Circuit-ID with the geographic location where the
   identified circuit terminates (such as the location of the wall jack)." Would it be the job of the DHCP server to do this correlation? I would assume it was a NM application function to do such correlation. 
2) In 2.2.1.2, s/same response. This is not useful since/same response, since/
Gonzalo Camarillo Former IESG member
No Objection
No Objection ()

                            
Jari Arkko Former IESG member
(was Discuss, No Objection) No Objection
No Objection (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.
Peter Saint-Andre Former IESG member
No Objection
No Objection ()

                            
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2011-02-04)
I've cleared my DISCUSS.  I have a remaining minor
comment - In the descriptions of the options, sentences like:

              When the Ver field = 1, this field represents
              latitude uncertainty.  The contents of this field is
              undefined for other values of the Ver field.

seem unnecessarily detailed.  Why not simply:

              This field represents
              latitude uncertainty.

The descriptions of many fields say nothing about the version number.

Ron Bonica Former IESG member
No Objection
No Objection ()

                            
Russ Housley Former IESG member
No Objection
No Objection ()

                            
Sean Turner Former IESG member
No Objection
No Objection ()

                            
Stewart Bryant Former IESG member
No Objection
No Objection (2010-12-01)
PIFF-LO term used but not defined
GML term used but not defined
Code:      GEOCONF_GEODETIC (16 bits). is "Option Code" in the fig above.
AType:     Altitude Type (4 bits). would be clearer with a ref to section 2.4 (appears in two places)


Tim Polk Former IESG member
No Objection
No Objection ()