Subject: Re: [dhcwg] review of draft-ietf-geopriv-dhcp-lbyr-uri-option

From: Alissa Cooper <[email-masked]>
Date: Thu, 1 Mar 2012 13:52:38 -0500

Picking this back up again in the hopes of achieving a resolution...

I think we're close to consensus on the relationship (or lack thereof, I guess), between the lifetime of a location URI and DHCP refresh mechanics. I suggest the following edit to Section 2.3 to clarify this:

===
OLD:

The Valid-For (LuriType=2) indicates how long, in seconds, the
   client is to consider this location URI (LuriType=1) valid
   before performing a refresh of this Option, with a refreshed
   LuriType=2 (Valid-For) value.  A client will update its Location URI
   either as part of the normal DHCP lease renewal, or through a
   renewal request sent due to the Valid-For timer reaching the value
   described in this document. Note that in the second case, the
   request could ask only for the LocationURI option.

   The Valid-For (LuriType=2) offers no meaningful information without
   an accompanying Location URI (LuriType=1), therefore a Valid-For
   (LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).

   If the Valid-For timer (LuriType=2) is received (solicited or
   unsolicited), it is RECOMMENDED that the client refresh the Location
   URI when the (Valid-For) counter value reaches approximately the
   halfway point.  For example, if 16000 was the initial value of the
   Valid-For (LuriType=2) value, when 8000 seconds have passed, the
   Option SHOULD be refreshed.  However, if every client on a network
   were to attempt a refresh at the same time, say if power when out
   and was brought back up at the same time, there would be an
   avalanche of location requests or transmissions. This can be avoided
   by varying the timers between the nodes on the same network.  This
   can be a good reason for not giving out the same Valid-for timer
   (amount) with each Location URI sent.

NEW:

The Valid-For (LuriType=2) indicates how long, in seconds, the
   client is to consider this location URI (LuriType=1) valid. The choice of the Valid-For value is a policy decision for the domain administrator. It can be statically configured on the DHCP server or provisioned dynamically (via an out-of-band exchange with a Location Information Server) as requests for location URIs are received. Expiration of the Valid-For timeframe does not trigger an automatic refresh of the location URI or impinge on DHCP mechanics in any other way -- it merely informs the client of the URI's valid lifetime.

   The Valid-For (LuriType=2) offers no meaningful information without
   an accompanying Location URI (LuriType=1), therefore a Valid-For
   (LuriType=2) MUST NOT be sent without a Location URI (LuriType=1).
===

If that satisfies the folks that have been discussing this, I think that concludes the DHC review of this document.

Alissa

On Dec 8, 2011, at 2:58 PM, Robert Sparks wrote:

> On 12/8/11 11:27 AM, Ted Lemon wrote:
>> On Dec 7, 2011, at 4:31 PM, Robert Sparks wrote:
>>> If I have it right, the essence of (this part of) your concern is that a dhcp server can't be constrained
>>> to go ask an external process for the information it needs to respond to a request. That is, it needs
>>> to be able to respond to the request with the data it has at the time the request arrives. The operational
>>> model is that the data you have to respond with is the kind of stuff the server admin would enter as
>>> configuration (and it's possible that the admin would need to type very fast). It would be ok for an external
>>> process to be providing new information, but not ok to require the server to ask that external process for
>>> information (or wait on it if information became stale, etc.)
>> 
>> So I've been ruminating about this since my rather terse response yesterday.   I think it's inappropriate for me as an individual or as a working group chair to be the only one weighing in on this.   I have some pretty strong opinions about what standards should require of DHCP servers, and I don't really think my opinions are inherently right—they're just opinions.
>> 
>> My essential concern about this document is that it seems to be placing expectations on a DHCP server that I think a typical DHCP server vendor would not be comfortable with.   At the same time, it's also clear to me that there are DHCP servers out there that could certainly serve this data, even if they did an in-band query from another server to fetch it.   I know Nominum's DHCP server can do this, and I am pretty sure CNR can do it as well.
>> 
>> So what I'm saying is that I don't really think it's wrong for a DHCP server to do this.   My concern is that it might not be practical for an IETF document to effectively _require_ that a DHCP server do this.
>> 
>> That's a fairly weak objection.   If this document were to go through and become a standard, and people didn't want to implement it, they just wouldn't implement it.
>> 
>> So perhaps it would help if the document were simply clearer about what it was asking of the DHCP server.   Right now it's a bit vague—all the out-of-band or in-band querying is implied rather than explicitly stated.   This is part of what I was getting at by asking about real expected use cases.
> Thanks Ted - I agree that we need to make the document clearer. This document should not be causing the refresh mechanics at a dhcp server or client to change, and it shouldn't be asking the server to do something
> fundamentally different from the kinds of things it already does in order to satisfy the request. I don't think we really have anybody asking for that, but we need to make the document clear so we're sure. This is where I was
> trying to focus the first part of the conversation (please do let me know if what I had in that message was right
> or not).
> 
> I'm going to take a stab at answering what I think you're asking for real expected use cases. But be aware
> of this context:
> 
> Email list conversations around how location references are created, moved around, and consumed have been
> notoriously difficult. It's easy to make assumptions, both as the reader and writer, when trying to make short
> points that lead folks to start talking passionately past each other. I think that might have happened early
> in the discussion of this document on this list. The way we've dealt with it is to capture things in the drafts
> (many now RFCs) in more detail. When things start to seem odd, please refer back to those to see if they
> clear up the oddness. A good touchstone starting place is RFC5808 section 3 (including its subsections).
> Because of the context, this is going to be verbose, and nit-sensitive - please read it as an attempt to 
> balance being specific with being concise.
> 
> The use case this draft is addressing is allowing a host to be configured (via dhcp) with a reference to
> a location object that it can hand off (convey) to other elements. If those elements are able to use the
> reference successfully, they get the location object and can use it as part of whatever function they
> are running (these elements are called location recipients).
> 
> The mechanism is intended to be general - there is no one specific expected use case, but some of the
> major instances used while developing the architecture include giving an application on your (fixed)
> desktop the ability to tell the local pizza delivery service where it is, and your mobile phone the ability
> to tell an emergency response center where it is.
> 
> The reference itself will not typically change rapidly - that's a major advantage of using a reference instead
> of providing location-by-value. If you had a deployment where you didn't need to worry about who you've
> given the reference to in the past, it could be configured once and have a very long life. In a more general
> deployment, the reference itself will need to occasionally change - but note that it does so based on the
> application use requirements, not inherently because the bits (location) that the reference points to might
> have changed. For instance, you might be willing to let some delivery service know were you are right now,
> but you don't want them to be able to use the reference you give them next week. This is where the location
> URI expiration notion becomes important - it lets the host know how long the location server will honor
> the reference. It lets the applications on the host make an informed decision about who they expose the
> reference to (I might be willing to give a reference to one of my friends that's good for several days, but
> I might choose not to hand one of those to the cab company in the city I'm visiting). 
> 
> There are some applications where you don't want to give the same reference to two different location recipients.
> Those applications would be better served using a different location configuration protocol than the one we're
> talking about here, such as HELD (RFC5985).
> 
> Let me stop there and ask if I'm on a path to address your question or if you were looking for something
> completely different.
> 
> Given what's above, I'd like to reiterate the point the we should clarify the draft to make it clear we're not
> trying to change what a dhcp client or server does. How we fix how it's trying to convey URI expiration needs
> to get that part right. I don't think we should remove it from the information that is configured, and I don't
> think we should tie it to the lease time (either by making it being exactly the lease time, or by artificially
> stimulating refreshes based on it. Rather, this is a management coordination task/policy decision for the
> administrative domain. A reasonable Location Information Service that is having its URIs configured into
> hosts using dhcp should be configured to have the exipiry of those URIs be at least as long as the expected
> lease time.
> 
> 
>> Robert, can you or James speak to that?   I don't want you to feel like I'm trying to checkmate you by getting you to admit to a use case that's forbidden—I don't think it's true that the use case I'm reluctant to encourage is in fact forbidden.   I just feel like right now the way this is expected to be used is unstated and vague, and it would be better if it were not.   That is, it would be better for you to really make a case for how you actually intend to use this option than for us to gloss over it.
>> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 01 Mar 2012 14:44:12 -0600

Alissa

thanks for the text offering. It looks good to me.

If the DHCWG has consensus with it, I'll 
incorporate it into the next rev and get that out before the -0X deadline.

James

At 12:52 PM 3/1/2012, Alissa Cooper wrote:
>I think we're close to consensus on the 
>relationship (or lack thereof, I guess), between 
>the lifetime of a location URI and DHCP refresh 
>mechanics. I suggest the following edit to Section 2.3 to clarify this:
>
>===
>OLD:
>
>    client is to consider this location URI 
> (LuriType=1) valid. The choice of the Valid-For 
> value is a policy decision for the domain 
> administrator. It can be statically configured 
> on the DHCP server or provisioned dynamically 
> (via an out-of-band exchange with a Location 
> Information Server) as requests for location 
> URIs are received. Expiration of the Valid-For 
> timeframe does not trigger an automatic refresh 
> of the location URI or impinge on DHCP 
> mechanics in any other way -- it merely informs 
> the client of the URI's valid lifetime.
>
>If that satisfies the folks that have been 
>discussing this, I think that concludes the DHC review of this document.
>
>Alissa
>
> >>> If I have it right, the essence of (this 
> part of) your concern is that a dhcp server can't be constrained
> >>> to go ask an external process for the 
> information it needs to respond to a request. That is, it needs
> >>> to be able to respond to the request with 
> the data it has at the time the request arrives. The operational
> >>> model is that the data you have to respond 
> with is the kind of stuff the server admin would enter as
> >>> configuration (and it's possible that the 
> admin would need to type very fast). It would be ok for an external
> >>> process to be providing new information, 
> but not ok to require the server to ask that external process for
> >> So I've been ruminating about this since my 
> rather terse response yesterday.   I think it's 
> inappropriate for me as an individual or as a 
> working group chair to be the only one weighing 
> in on this.   I have some pretty strong 
> opinions about what standards should require of 
> DHCP servers, and I don't really think my 
> opinions are inherently right—they're just opinions.
> >>
> >> My essential concern about this document is 
> that it seems to be placing expectations on a 
> DHCP server that I think a typical DHCP server 
> vendor would not be comfortable with.   At the 
> same time, it's also clear to me that there are 
> DHCP servers out there that could certainly 
> serve this data, even if they did an in-band 
> query from another server to fetch it.   I know 
> Nominum's DHCP server can do this, and I am pretty sure CNR can do it as well.
> >>
> >> So what I'm saying is that I don't really 
> think it's wrong for a DHCP server to do 
> this.   My concern is that it might not be 
> practical for an IETF document to effectively 
> _require_ that a DHCP server do this.
> >>
> >> That's a fairly weak objection.   If this 
> document were to go through and become a 
> standard, and people didn't want to implement 
> it, they just wouldn't implement it.
> >>
> >> So perhaps it would help if the document 
> were simply clearer about what it was asking of 
> the DHCP server.   Right now it's a bit 
> vague—all the out-of-band or in-band querying 
> is implied rather than explicitly 
> stated.   This is part of what I was getting at 
> by asking about real expected use cases.
> > Thanks Ted - I agree that we need to make the 
> document clearer. This document should not be 
> causing the refresh mechanics at a dhcp server 
> or client to change, and it shouldn't be asking the server to do something
> > fundamentally different from the kinds of 
> things it already does in order to satisfy the 
> request. I don't think we really have anybody 
> asking for that, but we need to make the 
> document clear so we're sure. This is where I was
> > trying to focus the first part of the 
> conversation (please do let me know if what I had in that message was right
> > or not).
> >
> > I'm going to take a stab at answering what I 
> think you're asking for real expected use cases. But be aware
> > of this context:
> >
> > Email list conversations around how location 
> references are created, moved around, and consumed have been
> > notoriously difficult. It's easy to make 
> assumptions, both as the reader and writer, when trying to make short
> > points that lead folks to start talking 
> passionately past each other. I think that might have happened early
> > in the discussion of this document on this 
> list. The way we've dealt with it is to capture things in the drafts
> > (many now RFCs) in more detail. When things 
> start to seem odd, please refer back to those to see if they
> > clear up the oddness. A good touchstone 
> starting place is RFC5808 section 3 (including its subsections).
> > Because of the context, this is going to be 
> verbose, and nit-sensitive - please read it as an attempt to
> > The use case this draft is addressing is 
> allowing a host to be configured (via dhcp) with a reference to
> > a location object that it can hand off 
> (convey) to other elements. If those elements are able to use the
> > reference successfully, they get the location 
> object and can use it as part of whatever function they
> > The mechanism is intended to be general - 
> there is no one specific expected use case, but some of the
> > major instances used while developing the 
> architecture include giving an application on your (fixed)
> > desktop the ability to tell the local pizza 
> delivery service where it is, and your mobile phone the ability
> > The reference itself will not typically 
> change rapidly - that's a major advantage of using a reference instead
> > of providing location-by-value. If you had a 
> deployment where you didn't need to worry about who you've
> > given the reference to in the past, it could 
> be configured once and have a very long life. In a more general
> > deployment, the reference itself will need to 
> occasionally change - but note that it does so based on the
> > application use requirements, not inherently 
> because the bits (location) that the reference points to might
> > have changed. For instance, you might be 
> willing to let some delivery service know were you are right now,
> > but you don't want them to be able to use the 
> reference you give them next week. This is where the location
> > URI expiration notion becomes important - it 
> lets the host know how long the location server will honor
> > the reference. It lets the applications on 
> the host make an informed decision about who they expose the
> > reference to (I might be willing to give a 
> reference to one of my friends that's good for several days, but
> > I might choose not to hand one of those to 
> the cab company in the city I'm visiting).
> >
> > There are some applications where you don't 
> want to give the same reference to two different location recipients.
> > Those applications would be better served 
> using a different location configuration protocol than the one we're
> > Let me stop there and ask if I'm on a path to 
> address your question or if you were looking for something
> > completely different.
> >
> > Given what's above, I'd like to reiterate the 
> point the we should clarify the draft to make it clear we're not
> > trying to change what a dhcp client or server 
> does. How we fix how it's trying to convey URI expiration needs
> > to get that part right. I don't think we 
> should remove it from the information that is configured, and I don't
> > think we should tie it to the lease time 
> (either by making it being exactly the lease time, or by artificially
> > stimulating refreshes based on it. Rather, 
> this is a management coordination task/policy decision for the
> > administrative domain. A reasonable Location 
> Information Service that is having its URIs configured into
> > hosts using dhcp should be configured to have 
> the exipiry of those URIs be at least as long as the expected
> > lease time.
> >
> >
> >> Robert, can you or James speak to that?   I 
> don't want you to feel like I'm trying to 
> checkmate you by getting you to admit to a use 
> case that's forbidden—I don't think it's true 
> that the use case I'm reluctant to encourage is 
> in fact forbidden.   I just feel like right now 
> the way this is expected to be used is unstated 
> and vague, and it would be better if it were 
> not.   That is, it would be better for you to 
> really make a case for how you actually intend 
> to use this option than for us to gloss over it.
> >>
> >