At 05:22 PM 3/9/2010, Thomson, Martin wrote:
>Responses inline.
>
> > -----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.
Martin - you have stated you have a problem with an ID, it's on you
to offer an alternative -- preferably in the form of text that can be
pasted into the ID. It's been this way in the IETF for more than a
decade. Please... ask Brian, as I know you don't/won't believe me.
As author, I have offered a solution. Stating that "that ain't gonna
work" isn't enough most of time, if you expect to make progress.
Stating you have no intention of deploying what's specified in a
particular ID is great -- but don't poke wholes in it without
sufficiently supplying what you consider to be a sound alternative.
You are admitting you will not (by stating above "As the draft
editor, I'd suggest that it is your responsibility to start and guide
discussion on this").
>Richard proposed one such solution, which might be appropriate.
if you have knowledge of such a solution -- please cute and paste his here
> > >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.
then you bring them to the other WG, if you feel so strongly. No one
is holding you back.
>
> > >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.
no it doesn't. if a client's <valid-for> timer goes off before the
lease timer, the client asks for an updated location URI. That
doesn't mean it has to ask for every other DHCP Option at the same time.
> > >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.
nor can it ever, that's why it becomes the burden of the client to
request for a fresh location URI whenever its attachment changes, or
the device power cycles.
>It only provides information when the Device makes a DHCP
>request. Thus, making it mandatory is largely pointless for this scenario.
in the above sentence, what is "it" referring to (the device, the
server, the location URI or the RAIO)?
>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.
same question as above -- in fact, it seems you have "it" in the
above sentence describing two different things, which I can't make out.
> > >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.
Directly quoted from Section 3.:
"It is RECOMMENDED to avoid building URIs, with any parameters,
larger than what a single DHCP response can be. However, if a
message is larger than 255 bytes, concatenation is allowed, per RFC
3396 [RFC3396]."
>It would be nice if the draft said this directly.
hmmm .... guess it does after all... ;-)
> > >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
I can add that as the encoding, np
(see, I'm not totally unreasonable)
>
> > >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).
oops - I'm wrong here.
So, in Section 1, there's this text about the LS and the Rule Holder:
"A Location Server (LS) stores the Target's location as a presence
document, called a Presence Information Date Format - Location
Object (PIDF-LO), defined in RFC 4119 [RFC4119]. The Location Server
is the entity contacted during the act of dereferencing a Target's
location. If the dereferencing entity has permission, defined in
[ID-GEO-POL], the location of the target will be received. The LS
will grant permission to location inquires based on the rules
established by a Rule Holder [RFC3693]. The LS has the ability to
challenge any request for a target's location, thereby providing
additive security properties before location revelation. "
You're saying that the Rule Holder doesn't "establish" the rules, but
contains the rules, right?
If I did a s/establish/contained
would you be satisfied with that?
As Jon Peterson has stated many times, the Target isn't the only one
setting rules for acquisition of location - often it is the ASP
(which could be acting according to a Judge's ruling - is his
frequent example).
>draft-ietf-geopriv-arch doesn't mention rule holder at all. It's a
>role that has no great influence on scenarios.
Rule Makers make the rules. There can be, and likely are more than
one Rule Maker affecting the location of each Target -- effectively
making the Rule Maker the Location Policy Server.
What entity is contains all those rules?
RFC 3693 says the rules are stored in the Rule Holder, which the
Location Server explicitly contacts.
What takes the place of the Location Policy Server in draft-ietf-geopriv-arch?
James
>--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
