Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums

From: "James M. Polk" <[email-masked]>
Date: Thu, 19 Apr 2007 16:30:38 -0500

At 04:20 PM 4/19/2007, Dawson, Martin wrote:
>"DHCP is not adequate because it doesn't meet multiple sets of 
>requirements as documented multiple times ..."

bologna

"documented multiple times" means in individual submissions

of which, zero facts were presented to substantiate

If DHCP were so inadequate, why is the DSL forum now going to specify 
it? Why does PacketCable define it?  These were fairly recent moves...

And, how many times has HELD been presented as if it were a product 
of an IETF WG?

James

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 19 Apr 2007 16:43:08 -0500

Martin

Exactly what products support HELD right now?

If you want location verification and location signing - are these 
deployed today?

Doesn't all these mean something has to be changed or upgraded?

Broadband providers in the US have given away FREE home routers to 
enable a service as recently as a year ago.  So, taking the stance 
that this won't happen is looking facts to the contrary in the eye 
and saying "that didn't happen" *or* "that's not going to happen"....

At 04:34 PM 4/19/2007, Dawson, Martin wrote:
>Does DHCP require a change to the residential CPE James? How long is it
>going to take to change every residential router in the world? Do you
>think it is an unreasonable requirement to not have to do this?
>
>You can't just object to HELD on the basis that you think it's been
>misrepresented. I don't accept that it has - but in any case, it's not a
>technical rationale.
>
>Cheers,
>Martin
>
>
>
>-----Original Message-----
>From: James M. Polk [mailto:[email-masked]]
>Sent: Friday, 20 April 2007 7:31 AM
>To: Dawson, Martin; John Schnizlein; Andrew Newton
>Cc: GEOPRIV WG; Allison Mankin; [email-masked]
>Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
>Hums
>
>------------------------------------------------------------------------------------------------
>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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 19 Apr 2007 15:38:40 -0700

DHCP is a layer 3 technology that talks directly to layer 2.

This is entirely acceptable, useful and right for NETWORK configuration. DHCP is an entirely sensible means of obtaining an IP address and _proposals_ for domain name prefixes and DNS servers.

DHCP should not be used for any other purpose. In particular to make use of DHCP for application configuration is a layer violation. Layer 7 should NEVER communicate with Layer 2 directly. When that happens we lose all the power and flexibility built into the IP stack. 

To give a concrete example of the problems caused. I am currently typing on a VeriSign machine in an office in VeriSign corporate HQ. In that environment the local DHCP server could provide me with useful and valid suggestions for all manner of services. But its still the wrong technology.

The problem is that when I take the machine to the Hilton Garden Inn down the road where I am staying I explicitly DO NOT want the hotel network to provide any more than an IP address. I am not going to use their DNS server and I certainly don't want to make use of any email server, DNS prefix, GEOPRV or any other application layer feature they might want to foist onto me. 

I am using the Hilton Garden Inn LAN, I am not joining their network. The machine is remaining on the VeriSign network.

DHCP is a fine technology for the task DHCP is designed to do. It is an inappropriate technology for application or service configuration. The proper infrastructure to support those needs is DNS, supplemented if necessary by HTTP or LDAP backing store (i.e. either discover the services via DNS directly or use DNS to discover where the directory service is to be found).

Looking at the history of UPnP and Zero Config it strikes me that attempting to manage networks through peer to peer broadcast or multicast have been a bust precisely because of this layer violation.

> Sent: Thursday, April 19, 2007 5:31 PM
> Cc: GEOPRIV WG; [email-masked]; Allison Mankin
> Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 
> Working Group Hums
> 
> If DHCP were so inadequate, why is the DSL forum now going to 
> specify it? Why does PacketCable define it?  These were 
> fairly recent moves...
> 
> And, how many times has HELD been presented as if it were a 
> product of an IETF WG?
> 
> James
> 
>

---

From: "David W. Hankins" <[email-masked]>
Date: Thu, 19 Apr 2007 16:47:26 -0700

> DHCP is a layer 3 technology that talks directly to layer 2.

DHCP is a technology that dynamically configures hosts.

If a host has a configuration knob that might reasonably and
properly be set by the systems administrator or the network you
are presently attached to, then it is reasonable and proper to
configure it via DHCP.

DHCP would be the wrong tool to configure how, in what frequency,
or in what manner an application would directly contact a specific
remotely administered service, such as a distant web server.  DNS
would be the correct tool for that sort of job, having as it does
a global reach, and fate sharing.

If GEOPRIV is truthfully a global service the client communicates
with directly without the local network operator's involvement,
then I think it should be configured by whatever global distribution
means is reasonable.

My impression is that GEOPRIV is a service that is provided by
the local network to which the client is attached, and as such
under the purview of that network's operator and DHCP, but I admit
to not following it very closely.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 19 Apr 2007 20:46:07 -0400

In the example you gave the Hilton is EXACTLY the network that MUST give you
your location, and Verisign, if they tried, would give a valid, but very
wrong location.

That is the point of using DHCP for location, you need the closest possible
server to get the right location.  You need a server that understands the L2
to which you are connected.  Anything L3 and farther has a big problem of
where, exactly, are you?  The proposals for L7 versions of location
configuration protocols suffer mightily from the problem of figuring out
where you are in the L2.  They have to go to great lengths to determine some
kind of identifier that they can unambiguously use to figure that out.  I
think we have (painfully) figured out a way though that morass that will
work in enough circumstances to be interesting, but it remains hard, very
hard, to identify the L2 when your server is sitting at L7.

So, make sure that when you go to the Hilton that you use it's location
server, or you may have a big problem if you have to make an emergency call
(or even order a pizza).

DHCP is an excellent choice for a location server for networks where the
DHCP infrastructure is present, and can reasonably be upgraded.  The L7 guys
point out, correctly, that that's a tall order in a lot of interesting
networks.  I think that is right.  I do think they believe L7 works on every
network.  I'm certain it doesn't.  

That's why the compromise of BOTH is probably required.  I know it's the
only way we are going to get anything done in the next year.

Brian

> From: Hallam-Baker, Phillip [mailto:[email-masked]]
> Sent: Thursday, April 19, 2007 6:39 PM
> To: James M. Polk; Dawson, Martin; John Schnizlein; Andrew Newton
> Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
> 
> This is entirely acceptable, useful and right for NETWORK configuration.
> DHCP is an entirely sensible means of obtaining an IP address and
> _proposals_ for domain name prefixes and DNS servers.
> 
> DHCP should not be used for any other purpose. In particular to make use
> of DHCP for application configuration is a layer violation. Layer 7 should
> NEVER communicate with Layer 2 directly. When that happens we lose all the
> power and flexibility built into the IP stack.
> 
> 
> To give a concrete example of the problems caused. I am currently typing
> on a VeriSign machine in an office in VeriSign corporate HQ. In that
> environment the local DHCP server could provide me with useful and valid
> suggestions for all manner of services. But its still the wrong
> technology.
> 
> The problem is that when I take the machine to the Hilton Garden Inn down
> the road where I am staying I explicitly DO NOT want the hotel network to
> provide any more than an IP address. I am not going to use their DNS
> server and I certainly don't want to make use of any email server, DNS
> prefix, GEOPRV or any other application layer feature they might want to
> foist onto me.
> 
> I am using the Hilton Garden Inn LAN, I am not joining their network. The
> machine is remaining on the VeriSign network.
> 
> 
> DHCP is a fine technology for the task DHCP is designed to do. It is an
> inappropriate technology for application or service configuration. The
> proper infrastructure to support those needs is DNS, supplemented if
> necessary by HTTP or LDAP backing store (i.e. either discover the services
> via DNS directly or use DNS to discover where the directory service is to
> be found).
> 
> Looking at the history of UPnP and Zero Config it strikes me that
> attempting to manage networks through peer to peer broadcast or multicast
> have been a bust precisely because of this layer violation.
> 
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 16:49:44 -0500

Pretty close to as many as support 3825 I'd expect.

The point of an "L7 LCP" is that it doesn't require changes to the CPE,
amongst other things.

So your agenda is to make carriers buy new residential routers for
everyone in the world? And you think that's a reasonable requirement? I
guess that could make sense... considering the source.

I think that broadband carriers in any given national jurisdiction could
introduce a functional L7 LCP service in less than twelve months. They'd
need to do pretty much what they need to do for DHCP except change all
their subscribers' CPE - and do all the interop with multiple vendors of
residential CPE.

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 7:43 AM
To: Dawson, Martin; John Schnizlein; Andrew Newton
Cc: GEOPRIV WG; Allison Mankin; [email-masked]
Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
Hums

Martin

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Apr 2007 09:21:02 +0200

DHCP is not a great choice in a mobile environment and also not when it 
comes to more complex location representations.

Ciao
Hannes

Brian Rosen wrote:
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv
>

---

From: "Dawson, Martin" <[email-masked]>
Date: Thu, 19 Apr 2007 16:34:29 -0500

Cheers,
Martin

-----Original Message-----
From: James M. Polk [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 7:31 AM
To: Dawson, Martin; John Schnizlein; Andrew Newton
Cc: GEOPRIV WG; Allison Mankin; [email-masked]
Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
Hums

bologna

James

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 20 Apr 2007 14:58:37 +0200

> comes to more complex location representations.

Why can't a mobile system have a locally valid DHCP record (+/- the length
of a wireless link)? For that matter, why couldn't a DHCP server have
real-time triangulation data, if it exists at all?

Do you mean more complex than can be expressed by RFC 4776 and RFC 3825 together?

     Brian

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 09:25:21 -0400

Agree that 3825 doesn't have the ability to express uncertainty and
confidence.  I don't wish to enhance it to do so at this time.

However, a triangulated WiFi location may have sufficiently low uncertainty
that it could be used for many purposes, including emergency calling,
without reporting what the actual uncertainty was.

In order to actually be useful if the endpoint was mobile, the endpoint
would have to implement a location update, since only it can requery DHCP to
get a new location.  The device that does the triangulation may not be
connected to the DHCP infrastructure.  In these circumstances, HELD may be a
better choice

Also, the most common initial deployments of WiFi will be that the clients
of an AP are given the location of the AP they are connected to as their
location, and that will often be civic.  RFC4776 would work well there.  I
expect that will be a very common deployment model.

Brian

> From: Dawson, Martin [mailto:[email-masked]]
> Sent: Friday, April 20, 2007 9:03 AM
> To: Brian E Carpenter; Hannes Tschofenig
> Cc: Brian Rosen; GEOPRIV WG; [email-masked]; Allison Mankin; John
> Schnizlein
> 3825 can actually only represent uncertainty to the extent that it can
> be conveyed by precision. This makes it unsuitable for the sort of
> arbitrary uncertainty around arbitrary location values you refer to.
> 
> Cheers,
> Martin
> 
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Friday, 20 April 2007 10:59 PM
> To: Hannes Tschofenig
> Cc: Brian Rosen; 'GEOPRIV WG'; Dawson, Martin; [email-masked]; 'Allison
> Mankin'; 'John Schnizlein'
> Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group
> Hums
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 20 Apr 2007 15:34:47 +0200

Hi Brian,

I quickly respond to your question but I do not plan to restart the last 
2 years of GEOPRIV discussions.
(I personally got the impression that the work on a GEOPRIV Layer 7 LCP 
solution was not really subject for discussion anymore. I acknowledge 
the fact that some folks still don't agree but most of the GEOPRIV 
working group members do. The main issue was which solution proposal to 
pick as a baseline for future work.)

Brian E Carpenter wrote:
>> DHCP is not a great choice in a mobile environment and also not when 
>> it comes to more complex location representations.
>
I should have written "RFC 3825 is not a great choice in a cellular 
environment". It is fine for a WLAN hotspot and an enterprise environment.
where it also competes with other layer 2 location configuration 
mechanisms and LLDP-MED.

> Do you mean more complex than can be expressed by RFC 4776 and RFC 
RFC 3825 describes a point.
Civic address formats (RFC 4776) have good applicability in fixed and 
some selected wireless environments (WLAN  hotspot).
They haven't been considered in the cellular space.

Location determination techniques produce other shape types. Please look at
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-pdif-lo-profile-06.txt

Ciao
Hannes

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2007 06:38:55 -0700

> Do you mean more complex than can be expressed by RFC 4776 and RFC 
If you look at DOCSIS cable, a single head end can subtend a huge amount
of cable in a single bridged domain. I seem to recall that in a rural 
Canadian
MSO I worked with it was 10's if not 100's of miles. I have no clue how
accurate GEOPRIV tries to be, but it sure seems that if the location of the
headend/dhcp relay is only piece of information you have, your accuracy is
going to be pretty lousy in many cases. If this information is intended for
first responders, it seems that all you're doing is pointing to the 
right haystack
to start searching for the needle.

       Mike, who probably shouldn't open his mouth here

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 09:43:30 -0400

The cable systems use the MAC address of the DOCSIS modem to determine which
subscriber is asking for location.  It's not perfect, because it is possible
to move a DOCSIS cablemodem from one house to another within some area
(often the service area of the CMTS, but in many systems, less than that).
The ability to move without detection is a problem the have for other
revenue sources and there is some effort being put into systems to detect
that kind of thing.  The incidence of moving the cablemodem without notice
is apparently very small.

You don't get the location of the server, you get the location of the
client.

Brian

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, April 20, 2007 9:39 AM
> To: Brian E Carpenter
> Cc: 'GEOPRIV WG'; 'Dawson,Martin'; [email-masked]; 'Allison Mankin'; 'John
> Schnizlein'
> Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
> 
> Brian E Carpenter wrote:

---

From: Michael Thomas <[email-masked]>
Date: Fri, 20 Apr 2007 07:14:27 -0700

> You don't get the location of the server, you get the location of the

That's only because there's an out of band arrangement with the MSO
and the subscriber. DHCP itself gives no such information. Wireless
substantially confuses the matter too. All it takes is two Pringle's cans
to cast that relationship in doubt.

       Mike

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 20 Apr 2007 10:29:57 -0400

Yup.

There are no mechanisms that work when the Pringles cans come out other than
actual endpoint measuring mechanisms (like GPS), which have their own
limitations.  The standards recommend methods for users to override the
automatic mechanisms when they do things like Pringle can extensions.  There
are a set of security issues on THAT, but it's still a workable notion.

The Cablelabs guys and individual MSOs have looked at this, and most believe
they can deploy a DHCP based location infrastructure that works pretty well.
The "pretty" part is mostly the problem of cablemodem moving.  Nothing is
perfect, nor does it need to be.  I think it's good enough, although I'd
really like them to be advancing on detecting cablemodem moves.  At least
that error source is a deliberate user action which is really already
prohibited by contract.

This whole area is complex because there isn't anything that works always.
There have to be options, both for access network operators, device
manufacturers and even end users to deal with all the variations in reality
that occur.

And again, nothing is going to be perfect.

Brian

> Sent: Friday, April 20, 2007 10:14 AM
> To: Brian Rosen
> Cc: 'Brian E Carpenter'; 'GEOPRIV WG'; 'Dawson,Martin'; [email-masked];
> 'Allison Mankin'; 'John Schnizlein'

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 20 Apr 2007 10:48:14 -0700

> From: David W. Hankins [mailto:[email-masked]] 

> DHCP is a technology that dynamically configures hosts.

That's not the point, the point here is that DHCP is not an Internet protocol. It is an IETF protocol but not an Internet protocol. It does not layer on the IP stack.

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 Apr 2007 13:57:05 -0400

Huh?  DHCP is carried in UDP and IP.  There is a little funkiness in the
DHCPv4 transport, which we wouldn't have need if IPv4 link-local addresses
had been defined when RFC 2131 was published.  DHCPv6 uses link-local
addresses and garden-variety IPv6.

- Ralph

On 4/20/07 1:48 PM, "Hallam-Baker, Phillip" <[email-masked]> wrote:

> That's not the point, the point here is that DHCP is not an Internet protocol.
> It is an IETF protocol but not an Internet protocol. It does not layer on the
> IP stack.
> 
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 20 Apr 2007 14:01:02 -0400

Please consult RFC 2131:

DHCP uses UDP as its transport protocol.  DHCP messages from a client
    to a server are sent to the 'DHCP server' port (67), and DHCP
    messages from a server to a client are sent to the 'DHCP client'  
port
    (68). A server with multiple network address (e.g., a multi-homed
    host) MAY use any of its network addresses in outgoing DHCP  
messages.

I don't know if UDP counts as an Internet protocol in your book.

On Apr 20, 2007, at 1:48 PM, Hallam-Baker, Phillip wrote:

> That's not the point, the point here is that DHCP is not an  
> Internet protocol. It is an IETF protocol but not an Internet  
> protocol. It does not layer on the IP stack.
>
>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 20 Apr 2007 10:59:31 -0700

OK how do I DHCP to the server on your network from my desk here?

(assuming that there are no NATs or firewalls)

If it was pure IP it would work. 

> From: Ralph Droms [mailto:[email-masked]] 
> Sent: Friday, April 20, 2007 1:57 PM
> To: Hallam-Baker, Phillip; David W. Hankins; [email-masked]
> Cc: GEOPRIV WG
> DHCPv4 transport, which we wouldn't have need if IPv4 
> link-local addresses had been defined when RFC 2131 was 
> published.  DHCPv6 uses link-local addresses and garden-variety IPv6.
> 
> - Ralph
> 
> 
> Internet protocol.
> > It is an IETF protocol but not an Internet protocol. It 
> does not layer 
> > on the IP stack.
> > 
> >

---

From: Ralph Droms <[email-masked]>
Date: Fri, 20 Apr 2007 14:02:18 -0400

Set up the relay agent in your router to point at my DHCP server.

- Ralph

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 20 Apr 2007 12:03:50 -0700

> Set up the relay agent in your router to point at my DHCP server.

There are also DHCPINFORM (v4) and Information-Request (v6) messages
which can transit the public Internet.  I think however, v4 fails
with NAT.

They are also not widely used for this purpose at the moment.

I was thinking about this while swimming yesterday.

Phillip's abstract problem is that multiple administrative domains
exist.

There is the physically attached network, which represents one
administrative domain which reaches to every place the broadcast
domain touches.  Someone is responsible for that network, and
the services it provides which facillitate access.

There is his 'home' network, which represents a second administrative
domain.

There is his 'work' network, which represents a final third domain
(or more).

It is likely that each of these three domains will wish to present
dynamic configuration contents.

One subset of them are only contextually useful when the physical and
administrative domains match (such as "what's the default gateway?"
and "where on earth is the network port I'm attached to?").

A second subset of them are contextually useful no matter where on the
Internet Phillip's laptop is connected (such as "where is my Inbox?"
or "where should I send my lat/long to?").

Right now, DHCP(v4|v6) has only been used to solve for the case where
the physical and administrative domains match.  Operationally.

DHCPv6 could easily be used for the case where the administrative
domain is extra to the physical broadcast domain by making use
of the Information-Request, and sorting values fetched this way
ahead of values got off the link.

DHCPv4 could potentially also be used for the same case, as the same
message exists, but we would need to introduce a signal for alternative
server behaviour ("reply to source address and port") to work around
NAT if that were desirable.

Both would require a single manual configuration element - the
address(es) of the DHCP servers the laptop wishes to acquire
super-administrative configuration from.  Probably delivered as
a domain name, possibly also advertised eg via DHCP while the
client is on the administrative domain's physical links.

Firewalls or NAT, even if a problem, really aren't, since software can
cache old values until it can freely observe the system again.  This
is just the same as network partition or packet loss problems.

---

From: "David W. Hankins" <[email-masked]>
Date: Fri, 20 Apr 2007 12:38:14 -0700

I'm sorry this reply is late.  I suspect you were stuck in ISC's
greylisters.

On Fri, Apr 20, 2007 at 10:48:14AM -0700, Hallam-Baker, Phillip wrote:
> That's not the point, the point here is that DHCP is not an Internet
> protocol. It is an IETF protocol but not an Internet protocol. It does
> not layer on the IP stack.

You're right, I muddled the point.

The point is that the ISO L(x) is not what one considers when judging
wether or not a certain configuration value "would make a good band
name.  I mean DHCP option."

What we (strive to) consider instead is the administrative scope
of the configuration information, and wether it matches common and
practical use of DHCP.

---

From: John Schnizlein <[email-masked]>
Date: Sun, 22 Apr 2007 18:41:11 -0400

The reason that DHCP is appropriate for information about the  
location of the host is that the scope of DHCP administration usually  
does match the local network to which the host is attached.  Location  
is local information.

John

---

From: "Dawson, Martin" <[email-masked]>
Date: Fri, 20 Apr 2007 08:03:09 -0500

Cheers,
Martin

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Friday, 20 April 2007 10:59 PM
To: Hannes Tschofenig
Cc: Brian Rosen; 'GEOPRIV WG'; Dawson, Martin; [email-masked]; 'Allison

> DHCP is not a great choice in a mobile environment and also not when
it 
> comes to more complex location representations.

Why can't a mobile system have a locally valid DHCP record (+/- the
length
of a wireless link)? For that matter, why couldn't a DHCP server have
real-time triangulation data, if it exists at all?

Do you mean more complex than can be expressed by RFC 4776 and RFC 3825
together?

     Brian

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 25 Apr 2007 06:50:28 -0700

But how does my application access it?

DHCP is not something that an application layer program should be allowed to perform. It is a security issue. For good reason performing DHCP operations requires privileges beyond mere network connectivity on Windows.

That is why configuring application programs from DHCP never caught on.  

> From: John Schnizlein [mailto:[email-masked]] 
> Sent: Sunday, April 22, 2007 6:41 PM
> To: David W. Hankins
> Cc: GEOPRIV WG; [email-masked]
> location of the host is that the scope of DHCP administration 
> usually does match the local network to which the host is 
> attached.  Location is local information.
> 
> John
> 
> > What we (strive to) consider instead is the administrative scope of 
> > the configuration information, and wether it matches common and 
> > practical use of DHCP.
> 
> 
> > If a host has a configuration knob that might reasonably 
> and properly 
> > be set by the systems administrator or the network you are 
> presently 
> > attached to, then it is reasonable and proper to configure it via 
> > DHCP.
> 
>

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 25 Apr 2007 11:25:15 -0700

> But how does my application access it?

The "proper" way from my point of view would be to read from your
system's option cache, so whatever DHCP the system does filters
down to applications.

> DHCP is not something that an application layer program should be allowed
> to perform.

Amen, brother!  But, you're preaching to the choir.

Macromedia Flash Proxy whatsimahoosits...sends a DHCPINFORM.
Doesn't set ciaddr, chaddr, htype or hlen.  Let me tell you,
becoming "similarly compatible" to this as other servers
evidently are was not an experience I would like to repeat.  [1]

Microsoft Industry Update Control.  Refuses to stop sending
DHCPINFORMs until any server responds with the WPAD option,
without placing that option on the PRL.  [2]

> It is a security issue. For good reason performing DHCP operations
> requires privileges beyond mere network connectivity on Windows.

I expect it doesn't, actually, as the relevant flash proxy bits
are sufficiently nonpriveleged.  That's via a "dot net" facility,
I've been told.  I see no reason to hold the system's option cache
secret from applications, when taht cache is got by a packet that
anyone can sniff off the wire.  I understand that applications
such as Opera, Firefox, and ID [3], are said to digest at least
one option in this way.

But, I'm not a "Windows guy," so if someone knows how that actually
works it would be helpful.  I just know that it works from the
outside looking in.

> That is why configuring application programs from DHCP never caught on.  

The reason you have made this statement is false.

But that doesn't, on its own, mean that the conclusion is false.  I
would say it certainly is not mainstream, but it is pervasive.

[1] http://marc.info/?l=dhcp-server&m=113466843320099&w=2

[2] http://marc.info/?l=dhcp-server&m=110928450802695&w=2

[3] http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol

[4] http://www.ietf.org/proceedings/99nov/I-D/draft-ietf-wrec-wpad-01.txt

    "The DHCP option code for WPAD is 252 by agreement of the DHC working 
     group chair."

    Possible alternative text:

    "I can't believe it's not IANA!"

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 25 Apr 2007 14:29:20 -0400

On most devices of interest, this is a non issue; they are small embedded
devices, like phones.

For other situations, for example a sip softclient running on a laptop, we
will specify an api on the O/S the application is running.  The api will
front end a set of "Location Configuration Protocols" of which DHCP is one.

Brian

> Sent: Wednesday, April 25, 2007 9:50 AM
> To: John Schnizlein; David W. Hankins
> to perform. It is a security issue. For good reason performing DHCP
> operations requires privileges beyond mere network connectivity on
> Windows.
>

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 25 Apr 2007 16:34:59 -0400

Sorry, bad choice of words. 

I'm not sure, but almost certainly not IETF.  IETF doesn't do apis.  I'm
trying to get MS+Apple+Linux and maybe some embedded OS folks to agree to
have a common api.  I don't know if that will work yet.

Brian

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, April 25, 2007 4:31 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Cc: [email-masked]; [email-masked]
> Brian,
> <we will specify an api on the O/S the application is running>
> 
> Who is "we", geopriv?
> 
> Guy Caron
> -----Message d'origine-----
> De : Brian Rosen [mailto:[email-masked]]
> Envoyé : 25 avril 2007 14:29
> À : 'Hallam-Baker, Phillip'; 'John Schnizlein'; 'David W. Hankins'
> Cc : 'GEOPRIV WG'; [email-masked]
> Objet : RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
>

---

From: <[email-masked]>
Date: Wed, 25 Apr 2007 16:30:53 -0400

Brian,

Who is "we", geopriv?

Guy Caron
-----Message d'origine-----

Brian

> > Cc: GEOFrom [email-masked] Thu Apr 26 10:19:33 2007
From: "Mark Brown" <[email-masked]>
To: "'John C Klensin'" <[email-masked]>,
	"'Simon Josefsson'" <[email-masked]>
Date: Wed, 25 Apr 2007 13:35:34 -0500
Cc: [email-masked], [email-masked], [email-masked]
Subject: RE: Withdrawal of Approval and Second Last
	Call:	draft-housley-tls-authz-extns

John,

I should have responded in my last email:

> I think you are being told --by a number of people and in
> different ways-- that there is a perception that having to ask
> for a license is seen as appreciably more burdensome and, for
> various reasons, risky than if a general license is granted
> without an application process.  My impression is that is a
> general perception around the IETF, not just related to your
> work or proposal.
> 
> So, rather than (or at least in addition to) telling others to
> go consult their lawyers to find out whether they could possibly
> work with your licensing requirements, I would encourage you to
> go back to your own and see if you can either (i) get the
> requirement to formally apply to you for a license removed or
> (ii) get a really good explanation as to why no strategy other
> than such an application is sufficient to meet your
> organizational needs.

Sure, I can do that too.  

I'm a newcomer to the IETF, and sometimes I find myself a bit out of the
loop regarding the general perception around the IETF.  I appreciate you
filling me in.

--mark

---

From: "Winterbottom, James" <[email-masked]>
Date: Wed, 25 Apr 2007 16:05:03 -0500

This is one of things we have talked about doing in the NENA VoIP Location WG.

> Sent: Thursday, 26 April 2007 6:31 AM