> -----Original Message-----
> From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On
> Behalf Of James M. Polk
> Sent: Wednesday, 10 March 2010 3:00 AM
> To: Thomson, Martin; geopriv@ietf.org
> Subject: Re: [Geopriv] Submitted draft-ietf-geopriv-dhcp-lbyr-uri-
> option-07
>
> Martin
>
> Thanks for the review
>
> At 11:48 PM 3/8/2010, Thomson, Martin wrote:
> >Hi James,
> >
> > > I addressed what I believe is the final open issue [...]
> >
> >Open issues that I'm aware of or have just noticed:
> >
> >1. The means by which authorization rules are provisioned is not
> specified.
>
> please provide some suggested text
I think that we've had discussions about this a number of times, but we don't have consensus on a particular solution. Until the WG has consensus, it's hard to propose text. As the draft editor, I'd suggest that it is your responsibility to start and guide discussion on this. I'm not interested in deploying this option, so don't try to push the problem on me.
Richard proposed one such solution, which might be appropriate.
> >2. Has this document been reviewed by the DHC WG?
>
> it will be cross-WGLCd just like the past IDs that involve DHCP,
> unless things have changed that I didn't notice.
Why wait until WGLC? I have concerns now, but I've not had them addressed to my satisfaction.
> >3. Valid-For is independent of the DHCP lease.
> >
> >I can see why this is necessary, but it introduces an interesting
> >deployment problem. One major DHCP implementation I'm aware of (and
> >use daily :*( ) does not update individual options independent of
> >the lease. The only effective way to update options with this
> >implementation is to release the IP address and renew it.
>
> that isn't necessarily true, and I'm not going to propose limiting
> this doc to how 1 implementation does things.
>
> If the valid-for is the same as the lease time, then the valid-for
> isn't necessary. That's why it's optional. Roger Marshall really
> wants this, so I incorporated it, and there might be times where the
> lease of an IP address (or other DHCP Options) is different than the
> time a location URI is to be considered *not stale*. The two do not
> have to be bound to the same timeframes, though sometimes they will
> be. I believe it flexibility here.
I think that the concern here is that the expiration of the information is different to the lease time, which introduces real problems in updating this data.
> >4. RAIO (RFC 3046) is mandated with MUST-strength language.
...
> >Furthermore, the draft talks about movement. RAIO only provides
> >information about the point of attachment when the DHCP request is
> >made; later requests to the location URI might happen after the
> >Target moves from this point. Thus, the LS and LG need to be able
> >to handle movement.
>
> a lot of the time, RAIO will be tied to the wiremap database, which
> is necessary.
>
> When a device is mobile, the RAIO will indicate which AP the Target
> is attached to, so I also think this is necessary.
RAIO can't provide a DHCP server with information about the current point of attachment of a Device when a URI is dereferenced. It only provides information when the Device makes a DHCP request. Thus, making it mandatory is largely pointless for this scenario. It might be helpful, but since we're making location determination out of scope, it's not really necessary to describe these sorts of details.
> >5. URI length.
> >
> >Quoting the draft:
> >
> > Per [RFC2131], subsequent LuriElement Options, which are
> > non-concatenated, overwrite the previous value.
> >
> >This is OK, though I don't think that 2131 says anything about this at
> all.
>
> In past drafts, the DHCP WG did in fact correct me about the 255
> length.
>
> Their opinion is that if a URI is longer than 255 bytes, "you need to
> pick a new URI".
>
> Therefore something like what 3396 proposes should cover us pretty
> well for the small number of cases that URIs go a little bit over.
You can't go "a little bit over". Based on my reading, URIs cannot exceed 255 bytes. It would be nice if the draft said this directly.
> >6. URI character encoding.
> >
> >The draft is silent on the way that URI characters are encoded into
> >a sequence of octets.
>
> what do you suggest?
UTF-8
> >7. (Easy one) the draft uses "Rule Holder" when it means "Rule Maker".
>
> Even simpler -- RFC 3693 says "Rule Holder", so I'm not changing
> anything. The idea of a "Rule Maker" might have been made up by me
> for all I know, but it has permeated list and meeting discussions --
> but it is not what the Geopriv Requirements RFC calls the entity.
<http://tools.ietf.org/html/rfc3693#page-5>:
Rule Holder: The entity that provides the rules associated with a
particular target for the distribution of location information.
It may either 'push' rules to a location server, or a location
server may 'pull' rules from the Rule Holder.
Rule Maker: The authority that creates rules governing access to
location information for a target (typically, this it the
target themselves).
draft-ietf-geopriv-arch doesn't mention rule holder at all. It's a role that has no great influence on scenarios.
--Martin
> Thanks
>
> James
>
>
> >--Martin
> >
> >[1] http://trac.tools.ietf.org/wg/geopriv/trac/ticket/26
>
> _______________________________________________
> Geopriv mailing list
> Geopriv@ietf.org
> https://www.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
