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

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Dec 2011 13:38:08 -0600

Circling back around on this draft's feedback from this WG.

Two folks have stated clearly on this list that the second lifetime 
timer <valid-for> (for considering whether or not the information at 
the location URI is good or stale (and needing a refresh)) is a bad 
idea within DHCP.  From this, I have 2 questions for this WG:

#1 - do others agree?

and

#2 - should the <valid-for> field (and idea) be removed from this ID?

As the doc's editor, I believe this is the last open item holding up 
this draft from progressing to the IESG.

Thank you for those who respond - even if it's only a yes/no to 
either question. This draft can't progress without a resolution to this issue.

James

At 03:01 PM 10/4/2011, Ralph Droms wrote:

>On Oct 4, 2011, at 4:57 PM 10/4/11, James M. Polk wrote:
>
> > At 03:31 PM 10/4/2011, Ralph Droms wrote:
> >
> >> On Oct 4, 2011, at 4:25 PM 10/4/11, Ted Lemon wrote:
> >>
> >> > On Oct 4, 2011, at 4:06 PM, James M. Polk wrote:
> >> >> I shortened the bullet, but what you say above is part of 
> what I suggested (i.e., needing a trigger upon change of an AP), 
> but that didn't satisfy the discussion in Geopriv.
> >> >
> >> > Interesting.   So they are willing to take a solution that 
> doesn't fix the problem, but reject a solution that does fix the 
> problem?   They can certainly fly in the face of reason like this 
> if they want, but that's not a good reason to change the way the 
> DHCP protocol works.
> >> >
> >> >>> In this situation you are not using DHCP, so it's not an issue.
> >> >>
> >> >> as cut-n-dry (or black-n-white) as you see this, others see 
> grey (unfortunately).
> >> >
> >> > This is actually the same as the previous question.   Even if 
> they were to use DHCP, a lifetime on the address wouldn't actually 
> solve the stated problem, because again the device needs to notice 
> that it's changed cells.
> >> >
> >> > And by the way, in both of these cases, even supposing that we 
> did change the DHCP protocol in the way that's been proposed, how 
> would the DHCP server know that the device was connecting through a 
> different access point or cell tower?
> >>
> >> And how does the host, after receiving the new URI from its DHCP 
> client, notify all the holders of that URI that the URI has changed?
> >
> > I'm a little twisted around, and not completely following your 
> question. Are you asking how does the host inform remote hosts that 
> the URI it sent previously is no longer good or needs to be replaced?
> >        - Answer - it needs to send the new URI to all the
> >          remote hosts again (each time), which IMO defeats
> >          the purpose, but this is what Geopriv wanted
>
>...and I may have missed this from the draft or other background: 
>does the host maintain a list of all other hosts to which it has 
>sent the URI so it can update those hosts?
>
>...which, as you say, seems to defeat the whole purpose of a "permanent" URI.
>
>- Ralph
>
> >
> >
> >> >
> >> >> The DHC WG stating there is a problem with the Valid-For 
> field within this document is something concrete that the (Geopriv) 
> chairs would need to address with and into DHC, IMO.
> >> >
> >> > Right, so I would be curious to hear from other DHC working 
> group members as to whether they have an opinion on whether the 
> DHCP protocol should be extended with an additional lifetime on 
> geopriv URIs.   Bear in mind that all DHCP clients would have to be 
> modified to support this feature.
> >>
> >> I don't think it's acceptable to extend the DHCP specification 
> and state machine to include an additional lifetime on geopriv URIs 
> for a couple of reasons:
> >>
> >> * in the specific case, the change doesn't solve the problem
> >> * in the general case, forcing the recoding of the core code in 
> DHCP clients and servers to accommodate this new option is inappropriate
> >>
> >> I- Ralph
> >
> > Thanks - I think this is why Robert asked the experts on DHCP.
> >
> > Other comments, concerns or questions?
> >
> > James
> >
> >
> >> >
> >> > Thoughts?   Comments?
> >> >
> >
>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Dec 2011 20:36:31 +0000

On Dec 6, 2011, at 2:38 PM, James M. Polk wrote:
Two folks have stated clearly on this list that the second lifetime timer <valid-for> (for considering whether or not the information at the location URI is good or stale (and needing a refresh)) is a bad idea within DHCP.  From this, I have 2 questions for this WG:

#1 - do others agree?

I'm one of the people who objected, so I guess I'm not "others," but I definitely agree.

Yes.

As the doc's editor, I believe this is the last open item holding up this draft from progressing to the IESG.

No, the other problem is that the document does not address the rather serious problem of provisioning the DHCP server with these URIs.   As I understand it, the expected use case is that the DHCP server will contact some other server to figure out which URI to send, before it sends the response to the DHCP client.   This is not consistent with general practice, and I don't think it's an appropriate use of the DHCP protocol.

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 06 Dec 2011 19:04:05 -0600

At 02:36 PM 12/6/2011, Ted Lemon wrote:
>>timer <valid-for> (for considering whether or not the information 
>>at the location URI is good or stale (and needing a refresh)) is a 
>>bad idea within DHCP.  From this, I have 2 questions for this WG:
>>
>>#1 - do others agree?
>

I'm not forgetting you here, I'm just looking for others to jump on 
or state a different opinion.

>>As the doc's editor, I believe this is the last open item holding 
>>up this draft from progressing to the IESG.
>
>No, the other problem is that the document does not address the 
>rather serious problem of provisioning the DHCP server with these 
>URIs.   As I understand it, the expected use case is that the DHCP 
>server will contact some other server to figure out which URI to 
>send, before it sends the response to the DHCP client.   This is not 
>consistent with general practice, and I don't think it's an 
>appropriate use of the DHCP protocol.

not consistent - yet - there are 3 standards track RFCs that have 
this functionality at their core RFC 3825 (from 2004), RFC 4776 and 
RFC 6225 (admittedly 6225 obsoletes 3825), so this function is 
already in line with previous specifications from within Geopriv using DHCP.

James

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Dec 2011 02:45:30 +0000

On Dec 6, 2011, at 8:04 PM, James M. Polk wrote:
not consistent - yet - there are 3 standards track RFCs that have this functionality at their core RFC 3825 (from 2004), RFC 4776 and RFC 6225 (admittedly 6225 obsoletes 3825), so this function is already in line with previous specifications from within Geopriv using DHCP.

RFC3285 and RFC6225 were never last-called in the DHC working group, and go quite strongly against existing practice.   I would like to see them deprecated—I don't expect that they'll ever see significant adoption.   So the fact that RFC6225 says to do something is not a good reason for future RFCs to say to do something similar.

Essentially the problem is that you've decided to use DHCP as a transport, and DHCP is not a transport.   If you need to do this sort of thing, you really ought to be doing it *after* DHCP, not as a part of DHCP.

BTW, these are my opinions; I'd be curious to know if other DHC working group participants agree, or think I'm out in left field.   In particular, has anybody implemented RFC6225?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 7 Dec 2011 21:39:56 +0000

On Dec 7, 2011, at 4:31 PM, Robert Sparks wrote:
For 6225, there could be an external service that's always letting the server know where a given dhc client
is, whether the client is asking or not, and while there are easy to envision scenarios where that wouldn't
be reasonable for scaling reasons (you would want the external service to be a little more clever in what it
chose to provide), I don't think that actually violates existing practice.

What is the *actual* deployment scenario?

---

From: Robert Sparks <[email-masked]>
Date: Wed, 07 Dec 2011 15:31:08 -0600

On 12/6/11 8:45 PM, Ted Lemon wrote:
> RFC3285 and RFC6225 were never last-called in the DHC working group, 
> and go quite strongly against existing practice.   I would like to see 
> them deprecated—I don't expect that they'll ever see significant 
> adoption.   So the fact that RFC6225 says to do something is not a 
> good reason for future RFCs to say to do something similar.
>
> Essentially the problem is that you've decided to use DHCP as a 
> transport, and DHCP is not a transport.   If you need to do this sort 
> of thing, you really ought to be doing it *after* DHCP, not as a part 
> of DHCP.
>
> BTW, these are my opinions; I'd be curious to know if other DHC 
> working group participants agree, or think I'm out in left field.   In 
> particular, has anybody implemented RFC6225?
>
Ted -

If I've understood what you've written before, I don't think 6225 goes 
as strongly against existing practice
as you state here, and I'd like to uplevel a little to see if I have, in 
fact, understood correctly.

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.)

For 6225, there could be an external service that's always letting the 
server know where a given dhc client
is, whether the client is asking or not, and while there are easy to 
envision scenarios where that wouldn't
be reasonable for scaling reasons (you would want the external service 
to be a little more clever in what it
chose to provide), I don't think that actually violates existing practice.

Am I completely wrong?

If I'm not wrong, then I think I have suggestions for changes to the 
dhcp-lbyr-uri-option draft that would
address this part of the concern.

RjS

---

From: Ted Lemon <[email-masked]>
Date: Thu, 8 Dec 2011 17:27:08 +0000

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.

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.

---

From: Robert Sparks <[email-masked]>
Date: Thu, 08 Dec 2011 13:58:18 -0600

On 12/8/11 11:27 AM, Ted Lemon wrote:
>> configuration (and it's possible that the admin would need to type 
>> very fast). It would be ok for an external
> 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.
>