Re: Seeking a new IAB Executive Director
After thanking those who volunteered I am pleased to announce that Joe Abley will be taken the token from Phil Roberts. I would also like to thank Phil for a job well done! --Olaf On 19Mar 2007, at 9:10 PM, Leslie Daigle wrote: All, Due to other commitments Phil Roberts will not be able to continue his role as Executive Director. Therefore the IAB is currently looking to appoint a replacement. (...) --- Olaf M. Kolkman NLnet Labs http://www.nlnetlabs.nl/ PGP.sig Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ADs speaking for their WGs (was: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68)
Spencer Dawkins wrote: - what we tell the WG chairs is that ADs have the power to make a decision for the working group, in order to break a deadlock. Jeff Schiller (one of the ADs who did the WG chair training for several years) was very clear that an AD can say, if you guys don't make a decision by date X, I'll make a decision for you. If this is not part of the community understanding, someone should be telling the WG chairs and ADs what the community understanding is. This is not how I understood it. The ADs can appoint new WG Chairs if they're unhappy with the old Chairs, they're not forced to accept one of the Chairs as document shepherd, and there is (or was) a potential dead loop where the reaponsible AD can say forever that (s)he doesn't like a WG draft because they're unfortunately forced to vote YES otherwise. But all that doesn't cover ADs speaking _directly_ for a WG wrt WG drafts, this would remove the first step in the appeal procedure for WGs. Please correct me if I got it wrong. Likely the rules for liaisons are a bit more convoluted, and the rules for WG termination are in RFC 2418 no matter what ION 3710 says. - We have been encouraging greater separation of roles (an extreme case of non-separated roles is a document editor who is also the working group chair, the document shepherd, and the responsible AD for the working group). We've been saying that having ADs chair WGs in their own area is not a good thing. We've been saying that having WG chairs edit major documents in their own area is not a good thing. We may want to provide guidance that having ADs chair WG meetings in their own area, especially where there is no other person acting as chair, is not a good thing, and that the ADs really need to find someone else who is willing to chair the meeting, and who is not involved as the next step on the appeals ladder. Yes. OTOH if an important author of drafts in a WG volunteers to be an AD and gets the job it's ugly if that would force them to give up their I-Ds. All areas (excl. gen) have two ADs, that offers some leaway. Frank ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68
OK James. Whatever. -Original Message- From: James M. Polk [mailto:[EMAIL PROTECTED] Sent: Friday, 20 April 2007 7:37 AM To: Dawson, Martin; John Schnizlein; GEOPRIV WG; ietf@ietf.org Subject: RE: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68 At 04:31 PM 4/19/2007, Dawson, Martin wrote: And there it is. You're going to have to justify the accusation, John. Barbara S has already said she thinks she'll be constrained to deploying a system such as this - so it's certainly not a hidden agenda on her behalf. Other than that, it constitutes about 1% of the reasons for needing a location protocol that works above IP. The conspiracy theory is quite simply wrong. energy and misrepresentation doesn't make things right either Cheers, Martin -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Friday, 20 April 2007 7:13 AM To: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68 It is worth recalling that a subset of the AD's and GeoPriv Chairs have pursued surprise changes to the advertised agenda before. The agenda of the GeoPriv WG meeting at IETF 57 was distinctly different from the one advertised, with the inclusion of a presentation by Jon Peterson on draft-ietf-geopriv-dhcp-lci-option at the beginning. During Agenda Bash, I objected to the insertion of this presentation without the knowledge of the authors, and was told that the author not present had been told. Jon's presentation was a well-organized ambush with slides in which he raised a wide variety of concerns about the draft that he had not (for that matter never did) post to the WG mailing list. On the day after the draft minutes of the meeting were posted on September 23, 2003, I posted clarification on the mailing list of the whitewash of the objection to the inclusion of that ambush presentation. With modifications, that draft became RFC 3825, and represents the then-consensus position that hosts should obtain and control information about their geographic locations. The alternative that may have been the hidden agenda at IETF 68 instead advocates that control of a host's geographic location reside with the network operator, and delivered through location servers. The only requirement for these location servers appears to be the business interests of their operators, following the model of existing cellular telephone networks. Advocates for this server-centric model have pushed a protocol called HELD, which may have been represented as an IETF product (based on individual-submission drafts) to operator groups. Some of the same advocates have also undertaken attacks on RFC 3825 with arcane arguments about claimed differences between uncertainty and the resolution of a (latitude, longitude) location. After one of the chairs requested a draft to clarify the meaning of resolution in RFC 3825, and the comments from IETF 67 were incorporated into a WG-approved draft, the chairs have arbitrarily labeled this draft: draft-ietf-geopriv-binary-lci-00 as Awaiting revision by author team. There is reason to suspect that the maneuvers in Prague are part of an agenda to move control over a host's location from the host to the network operator in order to create a business of providing it. There is a pattern with implications on the outcome of the WG, not just procedural lapse. John On Apr 18, 2007, at 8:59 PM, Ted Hardie wrote: Howdy, I'd like to make some comments on the issues discussed below. Before diving into the details, I'd like to make two meta-comments. First, I believe that the chairs' messages noted that they had received private messages of concern, and that their e-mail was expressed as a response to those messages. As chairs, it is their responsibility to take the community's concerns seriously and to respond to them. My reading of their response is that they believe that the IETF 68 meeting of GEOPRIV was sufficiently unusual that it requires us to be very careful to follow our standard procedures in following up the meeting, so that the overall process is obviously fair and is as transparent as possible. This serves the interests of those who were at the GEOPRIV meeting at IETF 68, as well as those who participate but could not physically attend the meeting. Reading Cullen's response, it looks like he saw this as the chairs' impression and reaction as individuals; maybe that is part of it, but I believe is important to see this in terms of the view of the participant community (of which the Chairs certainly form part). I also believe that their suggested response is basically do business as usual, and make sure that's obvious, which I believe is non-controversial as a way forward. Secondly, I believe that this response has picked up some style elements of the original chairs' message and exaggerated them, falling into quasi-legal
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: ADs speaking for their WGs
On 2007-04-20 12:07, Frank Ellermann wrote: Spencer Dawkins wrote: - what we tell the WG chairs is that ADs have the power to make a decision for the working group, in order to break a deadlock. Jeff Schiller (one of the ADs who did the WG chair training for several years) was very clear that an AD can say, if you guys don't make a decision by date X, I'll make a decision for you. If this is not part of the community understanding, someone should be telling the WG chairs and ADs what the community understanding is. This is not how I understood it. It seems fairly clear in RFC 2418 section 6.1: The Chair has the responsibility and the authority to make decisions, on behalf of the working group, regarding all matters of working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention. So the AD *does* have authority *when circumstances warrant*, but only on matters of process and staffing. I'm sure Jeff Schiller didn't mean any more than that - this rule doesn't allow an AD to take technical decisions unilaterally, but does allow an AD to make a consensus call if for some reason the WG Chairs can't do so. (And all subject to the regular appeal process, of course.) The ADs can appoint new WG Chairs if they're unhappy with the old Chairs, they're not forced to accept one of the Chairs as document shepherd, and there is (or was) a potential dead loop where the reaponsible AD can say forever that (s)he doesn't like a WG draft because they're unfortunately forced to vote YES otherwise. But all that doesn't cover ADs speaking _directly_ for a WG wrt WG drafts, this would remove the first step in the appeal procedure for WGs. Please correct me if I got it wrong. Speaking for? That would seem strange, even as an interpretation of when circumstances warrant such an intervention. But the quote above does seem to allow an AD to take over for a WG chair as far as running the discussion is concerned, exceptionally. And yes, that does make the first two stages of the appeal process (appeal to WG Chair and to AD) rather empty. Likely the rules for liaisons are a bit more convoluted, and the rules for WG termination are in RFC 2418 no matter what ION 3710 says. - We have been encouraging greater separation of roles (an extreme case of non-separated roles is a document editor who is also the working group chair, the document shepherd, and the responsible AD for the working group). We've been saying that having ADs chair WGs in their own area is not a good thing. We've been saying that having WG chairs edit major documents in their own area is not a good thing. We may want to provide guidance that having ADs chair WG meetings in their own area, especially where there is no other person acting as chair, is not a good thing, and that the ADs really need to find someone else who is willing to chair the meeting, and who is not involved as the next step on the appeals ladder. Yes. OTOH if an important author of drafts in a WG volunteers to be an AD and gets the job it's ugly if that would force them to give up their I-Ds. All areas (excl. gen) have two ADs, that offers some leaway. That's where recusals come from. And the General AD is at liberty to find another AD to sponsor his or her BOFs or drafts. I did that. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68
And there it is. You're going to have to justify the accusation, John. Barbara S has already said she thinks she'll be constrained to deploying a system such as this - so it's certainly not a hidden agenda on her behalf. Other than that, it constitutes about 1% of the reasons for needing a location protocol that works above IP. The conspiracy theory is quite simply wrong. Cheers, Martin -Original Message- From: John Schnizlein [mailto:[EMAIL PROTECTED] Sent: Friday, 20 April 2007 7:13 AM To: GEOPRIV WG; ietf@ietf.org Subject: Re: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68 It is worth recalling that a subset of the AD's and GeoPriv Chairs have pursued surprise changes to the advertised agenda before. The agenda of the GeoPriv WG meeting at IETF 57 was distinctly different from the one advertised, with the inclusion of a presentation by Jon Peterson on draft-ietf-geopriv-dhcp-lci-option at the beginning. During Agenda Bash, I objected to the insertion of this presentation without the knowledge of the authors, and was told that the author not present had been told. Jon's presentation was a well-organized ambush with slides in which he raised a wide variety of concerns about the draft that he had not (for that matter never did) post to the WG mailing list. On the day after the draft minutes of the meeting were posted on September 23, 2003, I posted clarification on the mailing list of the whitewash of the objection to the inclusion of that ambush presentation. With modifications, that draft became RFC 3825, and represents the then-consensus position that hosts should obtain and control information about their geographic locations. The alternative that may have been the hidden agenda at IETF 68 instead advocates that control of a host's geographic location reside with the network operator, and delivered through location servers. The only requirement for these location servers appears to be the business interests of their operators, following the model of existing cellular telephone networks. Advocates for this server-centric model have pushed a protocol called HELD, which may have been represented as an IETF product (based on individual-submission drafts) to operator groups. Some of the same advocates have also undertaken attacks on RFC 3825 with arcane arguments about claimed differences between uncertainty and the resolution of a (latitude, longitude) location. After one of the chairs requested a draft to clarify the meaning of resolution in RFC 3825, and the comments from IETF 67 were incorporated into a WG-approved draft, the chairs have arbitrarily labeled this draft: draft-ietf-geopriv-binary-lci-00 as Awaiting revision by author team. There is reason to suspect that the maneuvers in Prague are part of an agenda to move control over a host's location from the host to the network operator in order to create a business of providing it. There is a pattern with implications on the outcome of the WG, not just procedural lapse. John On Apr 18, 2007, at 8:59 PM, Ted Hardie wrote: Howdy, I'd like to make some comments on the issues discussed below. Before diving into the details, I'd like to make two meta-comments. First, I believe that the chairs' messages noted that they had received private messages of concern, and that their e-mail was expressed as a response to those messages. As chairs, it is their responsibility to take the community's concerns seriously and to respond to them. My reading of their response is that they believe that the IETF 68 meeting of GEOPRIV was sufficiently unusual that it requires us to be very careful to follow our standard procedures in following up the meeting, so that the overall process is obviously fair and is as transparent as possible. This serves the interests of those who were at the GEOPRIV meeting at IETF 68, as well as those who participate but could not physically attend the meeting. Reading Cullen's response, it looks like he saw this as the chairs' impression and reaction as individuals; maybe that is part of it, but I believe is important to see this in terms of the view of the participant community (of which the Chairs certainly form part). I also believe that their suggested response is basically do business as usual, and make sure that's obvious, which I believe is non-controversial as a way forward. Secondly, I believe that this response has picked up some style elements of the original chairs' message and exaggerated them, falling into quasi-legal language that hurts us as a group of folks trying to get this done. As I read the original message, the core is that there were three unusual aspects of the GEOPRIV meeting at IETF 68: the schedule changed, which had some unfortunate consequences; the meeting agenda changed more than usual; and the way the
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
Weekly posting summary for ietf@ietf.org
Total of 35 messages in the last 7 days. script run at: Fri Apr 20 00:53:01 EDT 2007 Messages | Bytes| Who +--++--+ 8.57% |3 | 16.17% |57419 | [EMAIL PROTECTED] 8.57% |3 | 13.31% |47265 | [EMAIL PROTECTED] 8.57% |3 | 4.52% |16061 | [EMAIL PROTECTED] 2.86% |1 | 8.73% |31004 | [EMAIL PROTECTED] 2.86% |1 | 7.42% |26343 | [EMAIL PROTECTED] 5.71% |2 | 4.20% |14925 | [EMAIL PROTECTED] 5.71% |2 | 3.97% |14095 | [EMAIL PROTECTED] 5.71% |2 | 3.45% |12235 | [EMAIL PROTECTED] 5.71% |2 | 3.25% |11558 | [EMAIL PROTECTED] 2.86% |1 | 4.91% |17431 | [EMAIL PROTECTED] 2.86% |1 | 3.76% |13362 | [EMAIL PROTECTED] 2.86% |1 | 3.74% |13272 | [EMAIL PROTECTED] 2.86% |1 | 2.54% | 9015 | [EMAIL PROTECTED] 2.86% |1 | 2.53% | 8987 | [EMAIL PROTECTED] 2.86% |1 | 2.20% | 7811 | [EMAIL PROTECTED] 2.86% |1 | 1.96% | 6973 | [EMAIL PROTECTED] 2.86% |1 | 1.90% | 6751 | [EMAIL PROTECTED] 2.86% |1 | 1.82% | 6456 | [EMAIL PROTECTED] 2.86% |1 | 1.69% | 5994 | [EMAIL PROTECTED] 2.86% |1 | 1.52% | 5406 | [EMAIL PROTECTED] 2.86% |1 | 1.42% | 5045 | [EMAIL PROTECTED] 2.86% |1 | 1.39% | 4934 | [EMAIL PROTECTED] 2.86% |1 | 1.29% | 4586 | [EMAIL PROTECTED] 2.86% |1 | 1.18% | 4200 | [EMAIL PROTECTED] 2.86% |1 | 1.13% | 4001 | [EMAIL PROTECTED] +--++--+ 100.00% | 35 |100.00% | 355129 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ADs speaking for their WGs
On 2007-04-20 14:44, Scott W Brim wrote: On 04/20/2007 08:35 AM, Brian E Carpenter wrote: It seems fairly clear in RFC 2418 section 6.1: The Chair has the responsibility and the authority to make decisions, on behalf of the working group, regarding all matters of working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention. So the AD *does* have authority *when circumstances warrant*, but only on matters of process and staffing. I'm sure Jeff Schiller didn't mean any more than that - this rule doesn't allow an AD to take technical decisions unilaterally, but does allow an AD to make a consensus call if for some reason the WG Chairs can't do so. (And all subject to the regular appeal process, of course.) My recollection is that Jeff made a technical decision and announced it, because everyone agreed the process was deadlocked. I don't recall that he ever took over for a WG chair, but there was agreement that the WG was stuck and a decision was required. Ah, but if the WG *agrees* to accept the AD's decision, that's OK. The rules in 2418 certainly allow an AD to ask a stuck WG Will you let me decide?. That's very different from deciding unilaterally. Sorry to be picky but I think this distinction matters. Brian ___ 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] Irregularity at the GEOPRIV Meeting at IETF 68
--On Thursday, 19 April, 2007 20:49 -0700 Bernard Aboba [EMAIL PROTECTED] wrote: In reading the messages posted to the list relating to the GEOPRIV WG meeting at IETF 68, it strikes me that we have a situation in which a deadlock was allowed to persist for much too long. Whether standard or alternative mechanisms of consensus determination can resolve this situation seems almost besides the point -- a huge amount of energy and time has already been wasted. Looking backwards, many of the IETF's most heated battles did in fact resolve themselves in clear outcomes, but only years afterwards once it become clear that one or more of the proposed approaches had little or no support in the marketplace. For example, recall the LDP vs. RSVP-TE debate. Given this, I would suggest that debating whether the IESG did the right or wrong thing at IETF 68 is somewhat besides the point. Instead, I would like to ask whether we are furthering the interest of the Internet community by allowing deadlocks to persist for long periods, rather than quickly recognizing them and defusing the situation by publishing the competing approaches, allowing the market to decide which one is best. Bernard, This comment worries me a bit, but it may be that I don't understand what you are suggesting. Ignoring GEOPRIV but speaking very generally, I think we actually have three different types of deadlock situations and that they call for different approaches. (1) Deadlock is apparent but not real: the WG actually has rough consensus, but the minority positions of a few people are being expressed loudly and aggressively enough to make the consensus less obvious and block progress. This calls, IMO, for some relatively aggressive behavior on the part of WG leadership and, if necessary, ADs. Letting the dissenters win by publishing their approach as co-equal with the agreed-upon better technical solution is bad for the Internet and bad for the IETF. (2) Deadlock is between solutions to different problems. What is needed is to move beyond arguments about which problem is the correct one to a clear definition of each of the problems and ways to determine which one is relevant to a particular case, followed by protocol options or different protocols to select the relevant problem and the approach that follows. (3) Deadlock is due to having competing approaches to the same problem with no clear technical justification for choosing one rather than another. Publishing all approaches and letting the marketplace decide almost guarantees non-interoperable solutions and is, IMO, a disservice to everyone involved. The WG needs to make a choice as to which one to recommend, even if it has to admit (and document) the fact that the solutions are equivalent and even if the choice is made at random, by delegation to a subcommittee or the AD, etc. If it cannot make or agree to a choice, then, IMO, the WG should be shut down and _at most_ documents be published as informational descriptions of the different approaches. From my point of view, any time the IETF makes a decision that lowers the odds of interoperability, we fail. If there are no alternatives to that sort of failure, we should be explicit about having done so and, ideally, explain and document the reasons why the failure occurred. Certainly, letting deadlocks drag out for a long time is another kind of failure and we should try to make them go away as described above. But replacing deadlock-failure with interoperability-failure is not necessarily a good choice. john ___ 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] Irregularities with the GEOPRIV Meeting at IETF 68
It is worth recalling that a subset of the AD's and GeoPriv Chairs have pursued surprise changes to the advertised agenda before. The agenda of the GeoPriv WG meeting at IETF 57 was distinctly different from the one advertised, with the inclusion of a presentation by Jon Peterson on draft-ietf-geopriv-dhcp-lci-option at the beginning. During Agenda Bash, I objected to the insertion of this presentation without the knowledge of the authors, and was told that the author not present had been told. Jon's presentation was a well-organized ambush with slides in which he raised a wide variety of concerns about the draft that he had not (for that matter never did) post to the WG mailing list. On the day after the draft minutes of the meeting were posted on September 23, 2003, I posted clarification on the mailing list of the whitewash of the objection to the inclusion of that ambush presentation. With modifications, that draft became RFC 3825, and represents the then-consensus position that hosts should obtain and control information about their geographic locations. The alternative that may have been the hidden agenda at IETF 68 instead advocates that control of a host's geographic location reside with the network operator, and delivered through location servers. The only requirement for these location servers appears to be the business interests of their operators, following the model of existing cellular telephone networks. Advocates for this server-centric model have pushed a protocol called HELD, which may have been represented as an IETF product (based on individual-submission drafts) to operator groups. Some of the same advocates have also undertaken attacks on RFC 3825 with arcane arguments about claimed differences between uncertainty and the resolution of a (latitude, longitude) location. After one of the chairs requested a draft to clarify the meaning of resolution in RFC 3825, and the comments from IETF 67 were incorporated into a WG-approved draft, the chairs have arbitrarily labeled this draft: draft-ietf-geopriv-binary-lci-00 as Awaiting revision by author team. There is reason to suspect that the maneuvers in Prague are part of an agenda to move control over a host's location from the host to the network operator in order to create a business of providing it. There is a pattern with implications on the outcome of the WG, not just procedural lapse. John On Apr 18, 2007, at 8:59 PM, Ted Hardie wrote: Howdy, I'd like to make some comments on the issues discussed below. Before diving into the details, I'd like to make two meta-comments. First, I believe that the chairs' messages noted that they had received private messages of concern, and that their e-mail was expressed as a response to those messages. As chairs, it is their responsibility to take the community's concerns seriously and to respond to them. My reading of their response is that they believe that the IETF 68 meeting of GEOPRIV was sufficiently unusual that it requires us to be very careful to follow our standard procedures in following up the meeting, so that the overall process is obviously fair and is as transparent as possible. This serves the interests of those who were at the GEOPRIV meeting at IETF 68, as well as those who participate but could not physically attend the meeting. Reading Cullen's response, it looks like he saw this as the chairs' impression and reaction as individuals; maybe that is part of it, but I believe is important to see this in terms of the view of the participant community (of which the Chairs certainly form part). I also believe that their suggested response is basically do business as usual, and make sure that's obvious, which I believe is non-controversial as a way forward. Secondly, I believe that this response has picked up some style elements of the original chairs' message and exaggerated them, falling into quasi-legal language that hurts us as a group of folks trying to get this done. As I read the original message, the core is that there were three unusual aspects of the GEOPRIV meeting at IETF 68: the schedule changed, which had some unfortunate consequences; the meeting agenda changed more than usual; and the way the group made progress was at the far end of our process. Any one of those, alone, might be enough to cause us to want to be careful of the follow-up. All of them together are definitely enough. Rather than push against how any one of these points got to be, let's see if we can agree on the way forward. I think, honestly, we already do, and bogging down in how we got here is not that useful. As you'll see below I see some mistakes I made here, and I suspect others do as well. Let's learn from them and move on. At 1:23 PM -0700 4/18/07, Cullen Jennings wrote: In the email below, the GEOPRIV chairs express serious
Re: ADs speaking for their WGs
On 04/20/2007 08:35 AM, Brian E Carpenter wrote: It seems fairly clear in RFC 2418 section 6.1: The Chair has the responsibility and the authority to make decisions, on behalf of the working group, regarding all matters of working group process and staffing, in conformance with the rules of the IETF. The AD has the authority and the responsibility to assist in making those decisions at the request of the Chair or when circumstances warrant such an intervention. So the AD *does* have authority *when circumstances warrant*, but only on matters of process and staffing. I'm sure Jeff Schiller didn't mean any more than that - this rule doesn't allow an AD to take technical decisions unilaterally, but does allow an AD to make a consensus call if for some reason the WG Chairs can't do so. (And all subject to the regular appeal process, of course.) My recollection is that Jeff made a technical decision and announced it, because everyone agreed the process was deadlocked. I don't recall that he ever took over for a WG chair, but there was agreement that the WG was stuck and a decision was required. ___ 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: ADs speaking for their WGs
Brian E Carpenter wrote: It seems fairly clear in RFC 2418 section 6.1: |The Chair has the responsibility and the authority to make decisions, | on behalf of the working group, regarding all matters of working | group process and staffing, in conformance with the rules of the | IETF. The AD has the authority and the responsibility to assist in | making those decisions at the request of the Chair or when | circumstances warrant such an intervention. So the AD *does* have authority *when circumstances warrant*, but only on matters of process and staffing. And actually only authority to assist in making those decisions, on request or on their own initiave. this rule doesn't allow an AD to take technical decisions unilaterally, but does allow an AD to make a consensus call if for some reason the WG Chairs can't do so. Yes. Anybody including Chairs and ADs is free to start some kind of poll, and it's up to the Chairs to decide if the outcome reflects a WG consensus. the quote above does seem to allow an AD to take over for a WG chair as far as running the discussion is concerned, exceptionally. Sure, for a WG meeting where the Chairs are absent somebody can be the meeting Chair, and if an AD, former AD, or anybody else with a clue about what's needed (agenda, minutes, jabber, etc. ) volunteers it's good. And of course it's better when the WG Chairs do this, in two cases I've watched that it took Harald about 20 minutes to post the draft minutes, complete as working visible on any browser PDF. if an important author of drafts in a WG volunteers to be an AD and gets the job it's ugly if that would force them to give up their I-Ds. All areas (excl. gen) have two ADs, that offers some leaway. That's where recusals come from. Recusals are okay, and losing an editor can be bad (from a WG's POV, maybe the editor is happy to have a good excuse to give up on the I-Ds :-) And the General AD is at liberty to find another AD to sponsor his or her BOFs or drafts. I did that. The general area should have two ADs, it could be quite overwhelming for the new AD otherwise. No issue this time, Russ is supposed to know what kind of informal infrastructure he inherited in addition to the stuff you've documented in the procdoc ION. I'd need an hour only to list what I've seen... Okay, I'm a slow typist. ;-) In another article you wrote: | Ah, but if the WG *agrees* to accept the AD's decision, that's OK. | The rules in 2418 certainly allow an AD to ask a stuck WG Will you | let me decide?. That's very different from deciding unilaterally. Yes, ADs and Chairs should be free to contribute like everybody else. But if they use magic words like WG consensus, publication request, hat on, etc. they better make sure that it doesn't trigger appeals. Frank ___ 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] Irregularity at the GEOPRIV Meeting at IETF 68
(1) Deadlock is apparent but not real: the WG actually has rough consensus, but the minority positions of a few people are being expressed loudly and aggressively enough to make the consensus less obvious and block progress. This calls, IMO, for some relatively aggressive behavior on the part of WG leadership and, if necessary, ADs. Letting the dissenters win by publishing their approach as co-equal with the agreed-upon better technical solution is bad for the Internet and bad for the IETF. This approach may or may not work, depending on who the dissenters are. Part of the problem with the loss of the multi-stage standards process over the years is that the importance of running code has been diminished within the IETF standard process, while in the market place the importance of implementation remains as strong as ever. As a result, if the dissenters represent all the likely implementers, refusing to publish their protocol will only result in approval of a bogo-standard with little industry support, and interoperability issues resulting from the lack of documentation for the approach that is actually widely implemented. For example, would it have served the interest of the Internet community to have suppressed the publication of the Ethernet specification in deference to IEEE 802 SNAP encapsulation? While the Ethernet proponents were in the minority within IEEE 802 at the time, their approach quickly became a defacto standard. As a result, I do not believe that a determination of rough consensus is sufficient; running code also needs to be taken into account. (2) Deadlock is between solutions to different problems. What is needed is to move beyond arguments about which problem is the correct one to a clear definition of each of the problems and ways to determine which one is relevant to a particular case, followed by protocol options or different protocols to select the relevant problem and the approach that follows. This particular case seems most relevant to the GEOPRIV WG case, where the argument seems to be about whether location is best handled on the host or in the network, and which protocol proposals meet the requirements. Rather than attempting to find a single best solution to a single set of requirements, it would probably have been better to recognize that in fact the two approaches may not be solving the same problem. (3) Deadlock is due to having competing approaches to the same problem with no clear technical justification for choosing one rather than another. Publishing all approaches and letting the marketplace decide almost guarantees non-interoperable solutions and is, IMO, a disservice to everyone involved. The WG needs to make a choice as to which one to recommend, even if it has to admit (and document) the fact that the solutions are equivalent and even if the choice is made at random, by delegation to a subcommittee or the AD, etc. If it cannot make or agree to a choice, then, IMO, the WG should be shut down and _at most_ documents be published as informational descriptions of the different approaches. I would disagree that flipping a coin in this case is likely to provide better interoperability either in the short or long term, since this takes into account neither consensus nor running code. One of the things we learn from the history of networking is that while competing approaches may persist in the short term, in the long term a single winner typically emerges. By suppressing all approaches in the interest of interoperability we merely delay the market-sorting process, prolonging the period of confusion. Even worse, the IETF track record does not suggest a strong ability to pick the eventual market leader, providing a significant probability that the IETF process will actually retard the development of market consensus. For example, an examination of initial track designations (Informational, Experimental, Standard) does not demonstrate a strong correlation with eventual success. Part of the problem here is that the intricacies of the IETF process, while well suited to the evolution of existing protocols, does not do a good job of developing innovative solutions to new problems. In such situations, the protocols most likely to succeed are those that only just work: proposals that are simple to implement and include only the bare minimum functionality necessary to solve the problem. It is exactly these kind of proposals that are most likely to fare poorly in the IETF review process. For examples, see Mark Handley's paper Why the Internet Only Just Works: http://www.cs.ucl.ac.uk/staff/M.Handley/papers/only-just-works.pdf If we look at the protocols that are at the core of much of what we do on the Internet today, many of them faced an uphill battle in the IETF, and were only accepted once their widespread implementation became too obvious to ignore (e.g. BGP). As a result, one
Re: ADs speaking for their WGs (was: [Geopriv] Irregularities with the GEOPRIV Meeting at IETF 68)
Spencer Dawkins wrote: - what we tell the WG chairs is that ADs have the power to make a decision for the working group, in order to break a deadlock. Jeff Schiller (one of the ADs who did the WG chair training for several years) was very clear that an AD can say, if you guys don't make a decision by date X, I'll make a decision for you. If this is not part of the community understanding, someone should be telling the WG chairs and ADs what the community understanding is. Yep, I did this... However, the devil is always in the details, and the details matter. On two occasions I stepped in to force a working group (two different working groups) to make progress. In one case I asked if a document was good enough and their was weak consensus, but not strong consensus. However the disagreement appeared to be over wording, not protocol. So I asked if the document was good enough if the alternative was WG shutdown. Suddenly the consensus was a lot stronger :-) I won't embarrass the WG by saying which one it was... you know who you are! But the more serious case involved IPSEC. The situation was thus: ~20 people for one proposal. ~20 people for a different proposal ~150 people for someone please decide so we can go off and implement! So I read the consensus as We want this solved. I then asked the authors of the two proposals if they could come to consensus by September 1, 1996 (this was in March of 1996). They said they would try. On August 29th I received a phone call telling me that they tried, but could not agree. So I decided. I chose one of the proposals and wrote up my decision and sent it to the WG list. I outlined my decision criteria, and how I viewed each proposal against the criteria, finally offering to publish the losing proposal as informational documents. My one regret is that I didn't publish my decision as an RFC. Just didn't think about it. I may dig it out of my e-mail archives and publish it at some point (with some additional historic background) as a historical RFC. The more time I get to refer to it, the more it makes sense to publish it. I will note that I don't believe I consulted with the WG chairs before my presentation, but my memory may be off (this was 11 years ago). However I do know that I had a very good working relationship with the chairs so perhaps this consultation was implicit. Certainly I do not believe that an AD should surprise' a WG chair in this fashion! But like I said, the devil is in the details. Why did I get away with it? Well here are some facts: o There was strong consensus that a decision needed to be made. Shutting down the WG and walking away was not considered an acceptable outcome. o I was viewed as being an honest broker. I wasn't aligned with one or the other proposal. o I was viewed as having the statue in the community to make such a decision. If not by de jure power, by personal power and influence. o I documented my decision and how it was arrived at. Was everyone happy in the end? Of course not. Part of the nature of leadership is occasionally having to make the hard decisions. And by definition, hard decisions are the ones that leave some people unhappy. But I believe it was the right thing to do at the time and perhaps history is showing the wisdom of the decision (or at least of making a decision instead of allowing deadlock to continue). As a side note. I find it a depressing trend in the IETF that we want our leadership to be process automatons dancing to a predetermined script. Only acting when there is a clear process to follow. I do not believe any group can be successful following such a course. I believe we need to choose leaders and then let them lead. We expect the IESG to be both technical leaders and process leaders. That is one tough role to fill. So they will never by perfect. However we should permit them to lead. If they abuse their power, then replace them, but don't remove the authority to make decisions and to truly lead from the positions themselves. -Jeff -- Jeffrey I. Schiller MIT Network Manager Information Services and Technology Massachusetts Institute of Technology 77 Massachusetts Avenue Room W92-190 Cambridge, MA 02139-4307 617.253.0161 - Voice [EMAIL PROTECTED] pgpr5zn8gidpY.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 4852 on IPv6 Enterprise Network Analysis - IP Layer 3 Focus
A new Request for Comments is now available in online RFC libraries. RFC 4852 Title: IPv6 Enterprise Network Analysis - IP Layer 3 Focus Author: J. Bound, Y. Pouffary, S. Klynsma, T. Chown, D. Green Status: Informational Date: April 2007 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 32 Characters: 76199 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-v6ops-ent-analysis-07.txt URL:http://www.rfc-editor.org/rfc/rfc4852.txt This document analyzes the transition to IPv6 in enterprise networks focusing on IP Layer 3. These networks are characterized as having multiple internal links and one or more router connections to one or more Providers, and as being managed by a network operations entity. The analysis focuses on a base set of transition notational networks and requirements expanded from a previous document on enterprise scenarios. Discussion is provided on a focused set of transition analysis required for the enterprise to transition to IPv6, assuming a Dual-IP layer (IPv4 and IPv6) network and node environment within the enterprise. Then, a set of transition mechanisms are recommended for each notational network. This memo provides information for the Internet community. This document is a product of the IPv6 Operations Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
