Subject: [Geopriv] Comments on draft-ietf-geopriv-dhcp-lbyr-uri-option-04

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 10 Mar 2009 22:43:26 -0500

(Maybe the WG is interested in this review also.  Apologies to James for the double-up.)

Hi James,

Thank you for considering DHCPv6 for this edit.

I see very little change aside from the format in this version.  So I reviewed changes only.

This statement is the only major textual change outside of the descriptions of the option format:

  If local configuration has the requirement of only assigning unique	
  Location URIs to each client, then unique LbyRs will be given out,	
  though they will all have the same location at the record, relieving	
  the backend Sighter from individually maintaining each location	
  independently.

And I don't believe it adds any value.  There are any number of reasons that a URI might be different for two different hosts - different location information, tracking, and accounting all spring to mind.

The rest of my comments relate to the option format.

I learned a few things about DHC in my discussions on LIS discovery.  Firstly, there is a strong desire to have very simple options.  I'd encourage you to take this to DHC and get some feedback there.  My opinion is shaped by the feedback I received, but you might find that this document elicits different feedback.

1. Sub-options seem like overkill for this field.  There are only two fields.  I see little benefit to be derived from extensibility - any extensibility can exist on the other end of the URI.

2. The Ver and Resv fields don't add enough value to warrant the (high) complexity they impose.  If you choose to ignore comment 1, their presence prevents a server from treating this option as having sub-options.

3. If you use sub-options, the field can be treated far more consistently.  Sub-options use 2 byte fields for type and length in DHCPv6, which allow for the fact that DHCPv6 doesn't allow option concatenation.  255 octets isn't always enough for a URL, even if we might like to keep it short, the requirement that it is hard to guess might cause it to get quite long.

Regards,
Martin

------------------------------------------------------------------------------------------------
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: "James M. Polk" <[email-masked]>
Date: Sun, 22 Mar 2009 14:10:44 -0500

At 10:42 PM 3/10/2009, Thomson, Martin wrote:
>And I don't believe it adds any value.

Martin, this was added by request, given that some believe all URIs 
need to have unique identifiers for every client, which not everyone 
seems to agree with.

I will rewrite this paragraph to make it read better though.

>  There are any number of reasons that a URI might be different for 
> two different hosts - different location information, tracking, and 
> accounting all spring to mind.

If the AP (along with another AP) does not do triangulation (figured 
out in the background), then any attached client will by definition 
have the same location information, so I'm not sure I understand your 
first example.

The same goes for tracking, why would the URI need to be different? 
But if it needs to be different, which the text covers, then a unique 
URI is provided.

The same goes for accounting as for tracking. The paragraph quoted 
above says that not every instance will have unique URIs, but if they 
are needed, they are given out.

>I learned a few things about DHC in my discussions on LIS 
>discovery.  Firstly, there is a strong desire to have very simple 
>options.  I'd encourage you to take this to DHC and get some 
>feedback there.  My opinion is shaped by the feedback I received, 
>but you might find that this document elicits different feedback.
>
>1. Sub-options seem like overkill for this field.

I made this Option offering have the same format as RFC4776, which 
the Shapes ID adopted too. I'd like to have consistency, and some 
implementers have asked for this as well.

>There are only two fields.  I see little benefit to be derived from 
>extensibility - any extensibility can exist on the other end of the URI.
>
>2. The Ver and Resv fields don't add enough value to warrant the 
>(high) complexity they impose.

I'm not sure I understand how complex these fields make the Option. 
Can you offer some reasons why?

>If you choose to ignore comment 1, their presence prevents a server 
>from treating this option as having sub-options.
>
>3. If you use sub-options, the field can be treated far more 
>consistently.  Sub-options use 2 byte fields for type and length in 
>DHCPv6, which allow for the fact that DHCPv6 doesn't allow option 
>concatenation.

I agree this needs to be corrected in the ID (that concatenation only 
applies to v4 Options)

>255 octets isn't always enough for a URL, even if we might like to 
>keep it short, the requirement that it is hard to guess might cause 
>it to get quite long.

this is something the DHC WG did give me loads of feedback on - that 
they don't believe URIs should ever be longer than 255 bytes.