Subject: [dhcwg] FW: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt

From: Ralph Droms <[email-masked]>
Date: Tue, 9 Dec 2008 06:20:12 -0500

Here's another draft the WG should review.  I need to find a least one  
volunteer to read the DHCP-related portions of this draft and publish  
comments.

- Ralph

>>> ------ Forwarded Message
>>> From: <[email-masked]>
>>> Reply-To: <[email-masked]>
>>> Date: Mon,  3 Nov 2008 17:00:01 -0800 (PST)
>>> To: <[email-masked]>
>>> Cc: <[email-masked]>
>>> Subject: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Geographic Location/Privacy Working
>>> Group
>>> of the IETF.
>>>
>>>
>>> Title           : Dynamic Host Configuration Protocol (DHCP) Option
>>> for a
>>> Location Uniform Resource Identifier (URI)
>>> Author(s)       : J. Polk
>>> Filename        : draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt
>>> Pages           : 11
>>> Date            : 2008-11-03
>>>
>>> This document creates a Dynamic Host Configuration Protocol (DHCP)
>>> Option for the downloading of a Uniform Resource Identifier (URI)
>>> pointing to the geolocation record of an endpoint.  This URI, called
>>> a Location-by-Reference (LbyR), points to a record on a location
>>> server which tracks the geolocation of the endpoint.  Once
>>> downloaded by an endpoint, this LbyR can be forwarded to another
>>> entity, to be dereferenced if this entity wants to learn the
>>> geolocation of the sender endpoint.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-
>>> 03.txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> ------ End of Forwarded Message
>>
>>
>>
>> James - I can't recall if your draft has been discussed in the dhc  
>> WG; I don't think it has.  Depending on its current state, it would  
>> be a good idea to get a quick review now, as the WG will likely be  
>> asked to review it during any last calls.
>>
>> - Ralph
>>
>> Begin forwarded message:
>>
>>> From: "Ralph Droms (rdroms)" <<mailto:[email-masked]>[email-masked] 
>>> >
>>> Date: November 3, 2008 8:16:49 PM EST
>>> To: "DHC WG" <<mailto:[email-masked]>[email-masked]>
>>> Subject: [dhcwg] FW: I-DAction:draft-ietf-geopriv-dhcp-lbyr-uri- 
>>> option-03.txt
>>>
>>> Here's another draft the WG should review.
>>>
>>> - Ralph
>>> ------ Forwarded Message
>>> From: <<mailto:[email-masked]>[email-masked]>
>>> Reply-To: <<mailto:[email-masked]>internet- 
>>> [email-masked]>
>>> Date: Mon,  3 Nov 2008 17:00:01 -0800 (PST)
>>> To: <<mailto:[email-masked]>[email-masked]>
>>> Cc: <<mailto:[email-masked]>[email-masked]>
>>> Subject: I-D Action:draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Geographic Location/Privacy  
>>> Working Group
>>> of the IETF.
>>>
>>>
>>> Title           : Dynamic Host Configuration Protocol (DHCP)  
>>> Option for a
>>> Location Uniform Resource Identifier (URI)
>>> Author(s)       : J. Polk
>>> Filename        : draft-ietf-geopriv-dhcp-lbyr-uri-option-03.txt
>>> Pages           : 11
>>> Date            : 2008-11-03
>>>
>>> This document creates a Dynamic Host Configuration Protocol (DHCP)
>>> Option for the downloading of a Uniform Resource Identifier (URI)
>>> pointing to the geolocation record of an endpoint.  This URI, called
>>> a Location-by-Reference (LbyR), points to a record on a location
>>> server which tracks the geolocation of the endpoint.  Once
>>> downloaded by an endpoint, this LbyR can be forwarded to another
>>> entity, to be dereferenced if this entity wants to learn the
>>> geolocation of the sender endpoint.
>>>
>>> A URL for this Internet-Draft is:
>>> <http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option- 
>>> >http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-lbyr-uri-option-
>>> 03.txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> <ftp://ftp.ietf.org/internet-drafts/>ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>> _______________________________________________
>>> I-D-Announce mailing list
>>> <mailto:[email-masked]>[email-masked]
>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>> Internet-Draft directories: <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
>>> or <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>
>>> ------ End of Forwarded Message
>>
>>
>

_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Wed, 24 Dec 2008 07:11:27 -0500

Here's my review of this draft.  Additional reviews welcome...

Is there a reason not to define a DHCPv6 version of this option in the  
same document?  Seems to me the syntax and semantics would be  
identical for IPv4 and IPv6; all that would be needed would be another  
section defining the DHCPv6 option syntax.

 From section 2.1:

    The <Valid-For> field indicates how long, in seconds, the client is
    to consider this Location-URI valid before performing a refresh of
    this Option, with a refreshed <Valid-For> value.  A refresh MAY be
    done merely at the normal DHCP refresh rate, or necessitated by this
    timer, perhaps with the client just requesting this Option be
    refreshed.

What is a "refresh of this option"?  I thought the idea is to hand out  
a permanent URI through which other devices can determine the location  
of the DHCP client host.  Under what circumstances would the URI  
change, esp. without the DHCP lease requiring a renewal?  It might be  
clearer to explain that "the client just requesting this Option be  
refreshed" would likely be implemented through a DHCPINFORM/DHCPACK  
message exchange.

Following paragraph:

    It is RECOMMENDED when the counter associated with this <valid-for>
    value has passed, the client perform a refresh of this Option.  For
    example, if 600 was the initial value of the <valid-for> field, when
    300 seconds have passed, the Option SHOULD be refreshed.

I think there might be some text missing in this paragraph referring  
to 1/2 of the <valid-for> value?

First paragraph of section 3:

    The [RFC3046] RAIO MUST be utilized to provide the appropriate
    indication to the DHCP Server where this DISCOVER or REQUEST message
    came from, in order to supply the correct response.  That said, this
    Option SHOULD NOT be in a DISCOVER message, because there is zero
    knowledge by the client of which Server will answer.

I infer that any one of the RAIO sub-options that can be used to  
determine a client's location would be appropriate here?  Is an RAIO  
the only way in which the DHCP server can determine the client's  
location?  I don't understand the last sentence and the importance of  
"zero knowledge by the client of which Server will answer."

Later in section 3:

    In the case of residential gateways being DHCP servers, they usually
    perform as DHCP clients in a hierarchical fashion up into a service
    provider's network DHCP server(s), or learn what information to
    provide via DHCP to residential clients through a protocol such as
    PPP.  In these cases, the Location-URI would likely indicate the
    residence's civic address to all wired or wireless clients within
    that residence.  This is not inconsistent with what's stated above.

I think the implication here is that the residential gateway will pass  
this option to any devices in the residential network.  If I have that  
right, it might improve clarity to state that expectation explicitly.

- Ralph

On Dec 9, 2008, at 6:20 AM, Ralph Droms wrote:

> Here's another draft the WG should review.  I need to find a least  
> one volunteer to read the DHCP-related portions of this draft and  
> publish comments.
>
> - Ralph
>
>
>>>> ------ Forwarded Message
>>>> Working
>>> WG; I don't think it has.  Depending on its current state, it  
>>> would be a good idea to get a quick review now, as the WG will  
>>> likely be asked to review it during any last calls.
>>>
>>> - Ralph
>>>
>>> Begin forwarded message:
>>>
>>>> Reply-To: <<mailto:[email-masked]>[email-masked] 
>>>> >

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 24 Dec 2008 13:54:37 -0600

Ralph

Thanks for the review.

I'll work on a response over the weekend and reply-all, for others 
awareness and comments.

Happy Holidays!

James

At 06:11 AM 12/24/2008, Ralph Droms wrote:
>>>>>From: "Ralph Droms (rdroms)" <<mailto:[email-masked]>[email-masked] >
>>>>>Reply-To: <<mailto:[email-masked]>[email-masked] >
>>>>>Internet-Draft directories: 
>>>>><http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
>>>>>or 
>>>>><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>>>