RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 PROTECTED] Envoyé : 25 avril 2007 14:29 À : 'Hallam-Baker, Phillip'; 'John Schnizlein'; 'David W. Hankins' Cc : 'GEOPRIV WG'; ietf@ietf.org Objet : RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 9:50 AM To: John Schnizlein; David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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. -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Sunday, April 22, 2007 6:41 PM To: David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 On Apr 20, 2007, at 3:38 PM, David W. Hankins wrote: 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. On Apr 19, 2007, at 7:47 PM, David W. Hankins wrote: On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Geopriv mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/geopriv ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
This is one of things we have talked about doing in the NENA VoIP Location WG. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, 26 April 2007 6:31 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 PROTECTED] Envoyé : 25 avril 2007 14:29 À : 'Hallam-Baker, Phillip'; 'John Schnizlein'; 'David W. Hankins' Cc : 'GEOPRIV WG'; ietf@ietf.org Objet : RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 9:50 AM To: John Schnizlein; David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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. -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Sunday, April 22, 2007 6:41 PM To: David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 On Apr 20, 2007, at 3:38 PM, David W. Hankins wrote: 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. On Apr 19, 2007, at 7:47 PM, David W. Hankins wrote: On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Geopriv mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/geopriv ___ Geopriv mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/geopriv 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] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 On Apr 20, 2007, at 3:38 PM, David W. Hankins wrote: 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. On Apr 19, 2007, at 7:47 PM, David W. Hankins wrote: On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Friday, 20 April 2007 10:59 PM To: Hannes Tschofenig Cc: Brian Rosen; 'GEOPRIV WG'; Dawson, Martin; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums On 2007-04-20 09:21, Hannes Tschofenig wrote: 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 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] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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. -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Sunday, April 22, 2007 6:41 PM To: David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 On Apr 20, 2007, at 3:38 PM, David W. Hankins wrote: 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. On Apr 19, 2007, at 7:47 PM, David W. Hankins wrote: On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
On Wed, Apr 25, 2007 at 06:50:28AM -0700, Hallam-Baker, Phillip wrote: 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-serverm=113466843320099w=2 [2] http://marc.info/?l=dhcp-serverm=110928450802695w=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! -- David W. HankinsIf 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 pgpALeINh5ezC.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 9:50 AM To: John Schnizlein; David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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. -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Sunday, April 22, 2007 6:41 PM To: David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 On Apr 20, 2007, at 3:38 PM, David W. Hankins wrote: 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. On Apr 19, 2007, at 7:47 PM, David W. Hankins wrote: On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 4:31 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 PROTECTED] Envoyé : 25 avril 2007 14:29 À : 'Hallam-Baker, Phillip'; 'John Schnizlein'; 'David W. Hankins' Cc : 'GEOPRIV WG'; ietf@ietf.org Objet : RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 25, 2007 9:50 AM To: John Schnizlein; David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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. -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Sunday, April 22, 2007 6:41 PM To: David W. Hankins Cc: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 On Apr 20, 2007, at 3:38 PM, David W. Hankins wrote: 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. On Apr 19, 2007, at 7:47 PM, David W. Hankins wrote: On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Geopriv mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/geopriv ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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: 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 -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 6:39 PM To: James M. Polk; Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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. -Original Message- From: James M. Polk [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 5:31 PM To: Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 PROTECTED] Sent: Friday, 20 April 2007 7:31 AM To: Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; Allison Mankin; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 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] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 PROTECTED] Sent: Friday, 20 April 2007 7:43 AM To: Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; Allison Mankin; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 PROTECTED] Sent: Friday, 20 April 2007 7:31 AM To: Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; Allison Mankin; ietf@ietf.org Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 --- - 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] 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] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 -Original Message- From: Dawson, Martin [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 9:03 AM To: Brian E Carpenter; Hannes Tschofenig Cc: Brian Rosen; GEOPRIV WG; ietf@ietf.org; Allison Mankin; John Schnizlein Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED] Sent: Friday, 20 April 2007 10:59 PM To: Hannes Tschofenig Cc: Brian Rosen; 'GEOPRIV WG'; Dawson, Martin; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums On 2007-04-20 09:21, Hannes Tschofenig wrote: 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 -- -- 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] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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: On 2007-04-20 09:21, Hannes Tschofenig wrote: 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? 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 3825 together? 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 Brian Ciao Hannes ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 9:39 AM To: Brian E Carpenter Cc: 'GEOPRIV WG'; 'Dawson,Martin'; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums Brian E Carpenter wrote: On 2007-04-20 09:21, Hannes Tschofenig wrote: 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? 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
Brian Rosen wrote: 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. 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 Brian -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 9:39 AM To: Brian E Carpenter Cc: 'GEOPRIV WG'; 'Dawson,Martin'; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums Brian E Carpenter wrote: On 2007-04-20 09:21, Hannes Tschofenig wrote: 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? 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 10:14 AM To: Brian Rosen Cc: 'Brian E Carpenter'; 'GEOPRIV WG'; 'Dawson,Martin'; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums Brian Rosen wrote: 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. 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 Brian -Original Message- From: Michael Thomas [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 9:39 AM To: Brian E Carpenter Cc: 'GEOPRIV WG'; 'Dawson,Martin'; ietf@ietf.org; 'Allison Mankin'; 'John Schnizlein' Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums Brian E Carpenter wrote: On 2007-04-20 09:21, Hannes Tschofenig wrote: 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? 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
On 2007-04-20 09:21, Hannes Tschofenig wrote: 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
Brian E Carpenter wrote: On 2007-04-20 09:21, Hannes Tschofenig wrote: 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? 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 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
From: David W. Hankins [mailto:[EMAIL PROTECTED] On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: DHCP is a layer 3 technology that talks directly to layer 2. 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 PROTECTED] wrote: From: David W. Hankins [mailto:[EMAIL PROTECTED] On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: DHCP is a layer 3 technology that talks directly to layer 2. 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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: From: David W. Hankins [mailto:[EMAIL PROTECTED] On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: DHCP is a layer 3 technology that talks directly to layer 2. 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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. -Original Message- From: Ralph Droms [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 1:57 PM To: Hallam-Baker, Phillip; David W. Hankins; ietf@ietf.org Cc: GEOPRIV WG Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 PROTECTED] wrote: From: David W. Hankins [mailto:[EMAIL PROTECTED] On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: DHCP is a layer 3 technology that talks directly to layer 2. 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
Set up the relay agent in your router to point at my DHCP server. - Ralph On 4/20/07 1:59 PM, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: 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. -Original Message- From: Ralph Droms [mailto:[EMAIL PROTECTED] Sent: Friday, April 20, 2007 1:57 PM To: Hallam-Baker, Phillip; David W. Hankins; ietf@ietf.org Cc: GEOPRIV WG Subject: Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 PROTECTED] wrote: From: David W. Hankins [mailto:[EMAIL PROTECTED] On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: DHCP is a layer 3 technology that talks directly to layer 2. 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
On Fri, Apr 20, 2007 at 02:02:18PM -0400, Ralph Droms wrote: 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. -- David W. HankinsIf 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 pgpky1jeKfyzI.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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. -- David W. HankinsIf 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 pgphoF5V2vJn7.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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. -Original Message- From: James M. Polk [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 5:31 PM To: Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
On Thu, Apr 19, 2007 at 03:38:40PM -0700, Hallam-Baker, Phillip wrote: 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. HankinsIf 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 pgpUBecRJKYQm.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums
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 -Original Message- From: Hallam-Baker, Phillip [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 6:39 PM To: James M. Polk; Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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. -Original Message- From: James M. Polk [mailto:[EMAIL PROTECTED] Sent: Thursday, April 19, 2007 5:31 PM To: Dawson, Martin; John Schnizlein; Andrew Newton Cc: GEOPRIV WG; ietf@ietf.org; Allison Mankin Subject: RE: [Geopriv] Confirmation of GEOPRIV IETF 68 Working Group Hums 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1
