From bmanning at vacation.karoshi.com Fri Jan 26 11:14:29 2001 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 26 Jan 2001 16:14:29 +0000 (UCT) Subject: Closure? Message-ID: <200101261614.QAA17345@vacation.karoshi.com> Good morning folks. This is to remind you that ARIN is still holding out on accepting the IAB/IESG recommendations for inital IPv6 delegation/allocation sizes. There was some lively discussion at the last mtg but the concerns generally came down to... "this makes me nervous and I don't understand it all to well." Yes, there are operational concerns but quite frankly, the number of people in the ARIN region that are able/willing to explore IPv6 seems to be either very small, not willing to share experiences, or are happy with the 6bone delegations. ARIN has pretty much removed the barriers to entry with the zero-cost delegation policy in place. Unless a viable counter proposal or modification to the existing IAB/IESG proposal that has been accepted by RIPE and APNIC, I'm going to recommend to the ARIN council that silence is consent and ARIN should adopt the IAB/IESG proposal for a /48 being the default delegation size, subject to review, based on operational experience. --bill From Marc.Blanchet at viagenie.qc.ca Fri Jan 26 15:09:25 2001 From: Marc.Blanchet at viagenie.qc.ca (Marc Blanchet) Date: Fri, 26 Jan 2001 15:09:25 -0500 Subject: Closure? In-Reply-To: <200101261614.QAA17345@vacation.karoshi.com> Message-ID: <5.0.2.1.1.20010126150802.02c28af8@mail.viagenie.qc.ca> At/? 16:14 2001-01-26 +0000, bmanning at vacation.karoshi.com you wrote/vous ?criviez: >Good morning folks. as a ca*net3 representative, we do agree with the IESG/IAB proposal. > This is to remind you that ARIN is still holding out on accepting the >IAB/IESG recommendations for inital IPv6 delegation/allocation sizes. There >was some lively discussion at the last mtg but the concerns generally came >down to... "this makes me nervous and I don't understand it all to well." >Yes, there are operational concerns but quite frankly, the number of people >in the ARIN region that are able/willing to explore IPv6 seems to be either >very small, not willing to share experiences, or are happy with the 6bone >delegations. ARIN has pretty much removed the barriers to entry with the >zero-cost delegation policy in place. > > Unless a viable counter proposal or modification to the existing >IAB/IESG proposal that has been accepted by RIPE and APNIC, I'm going >to recommend to the ARIN council that silence is consent and ARIN should >adopt the IAB/IESG proposal for a /48 being the default delegation size, for any organisation. (obvious but just want to make sure...) >subject to review, based on operational experience. > >--bill Regards, Marc. Marc Blanchet Viag?nie inc. tel: 418-656-9254 http://www.viagenie.qc.ca ---------------------------------------------------------- Normos (http://www.normos.org): Internet standards portal: IETF RFC, drafts, IANA, W3C, ATMForum, ISO, ... all in one place. From jfleming at anet.com Sat Jan 27 17:43:28 2001 From: jfleming at anet.com (Jim Fleming) Date: Sat, 27 Jan 2001 16:43:28 -0600 Subject: silence is consent ......Re: Closure? References: <200101261614.QAA17345@vacation.karoshi.com> Message-ID: <0a3101c088b2$9d656cc0$af00a8c0@dotarizona.com> "silence is consent" ....??? Once someone has a unique, persistent, 32-bit "site id", they can use FREE IPv8 addressing...which is compatible with IPv6....and can be routed across the legacy IPv4 transport...in the short run... ...silence may mean that people are busy routing around the fees, taxes, etc. of the government-backed IPv4 implosion... Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: To: Sent: Friday, January 26, 2001 10:14 AM Subject: Closure? > > Good morning folks. > > This is to remind you that ARIN is still holding out on accepting the > IAB/IESG recommendations for inital IPv6 delegation/allocation sizes. There > was some lively discussion at the last mtg but the concerns generally came > down to... "this makes me nervous and I don't understand it all to well." > Yes, there are operational concerns but quite frankly, the number of people > in the ARIN region that are able/willing to explore IPv6 seems to be either > very small, not willing to share experiences, or are happy with the 6bone > delegations. ARIN has pretty much removed the barriers to entry with the > zero-cost delegation policy in place. > > Unless a viable counter proposal or modification to the existing > IAB/IESG proposal that has been accepted by RIPE and APNIC, I'm going > to recommend to the ARIN council that silence is consent and ARIN should > adopt the IAB/IESG proposal for a /48 being the default delegation size, > subject to review, based on operational experience. > > --bill > From smarcus at genuity.com Mon Jan 29 14:40:16 2001 From: smarcus at genuity.com (J. Scott Marcus) Date: Mon, 29 Jan 2001 14:40:16 -0500 Subject: Closure? In-Reply-To: <5.0.2.1.1.20010126150802.02c28af8@mail.viagenie.qc.ca> References: <200101261614.QAA17345@vacation.karoshi.com> Message-ID: <3.0.5.32.20010129144016.00aa6c40@pobox3.genuity.com> At 15:09 01/26/2001 -0500, Marc Blanchet wrote: >> Unless a viable counter proposal or modification to the existing >>IAB/IESG proposal that has been accepted by RIPE and APNIC, I'm going >>to recommend to the ARIN council that silence is consent and ARIN should >>adopt the IAB/IESG proposal for a /48 being the default delegation size, > >for any organisation. (obvious but just want to make sure...) Note quite. As I understand it, Marc, a /48 would also be the standard allocation for a _home_ connection, unless it was absolutely certain that there would never be a subnet behind that connection. (Thus, dial-up connections might possibly be limited to a /64; however, the recommendation seems to discount this possibility.) The IAB/IESG recommendation says: > ... It is not obvious, however, that all edge networks are likely to be >recursively subnetted; an individual PC in a home, or a single cell in >a mobile telephone network, for example, may or may not be further >subnetted (depending whether they are acting as, e.g., gateways to >personal, home, or vehicular networks). When a network number is >delegated to a place that will not require subnetting, therefore, it >might be acceptable for an ISP to give a single 64 bit prefix - >perhaps shared among the dial-in connections to the same ISP router. >However this decision may be taken in the knowledge that there is >objectively no shortage of /48s, and the expectation that personal, >home and vehicle networks will become the norm. Indeed, it is widely >expected that all IPv6 subscribers, whether domestic (homes), mobile >(vehicles or individuals), or enterprises of any size, will eventually >possess multiple always-on hosts, at least one subnet with the >potential for additional subnetting, and therefore some internal >routing capability. Note that in the mobile environment, the device >connecting a mobile site to the network may in fact be a third >generation cellular telephone. In other words the subscriber >allocation unit is not always a host; it is always potentially a site... Thus, the allocation of a /48 is by no means limited to organizations. Cheers, - Scott From bmanning at vacation.karoshi.com Mon Jan 29 15:28:33 2001 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 29 Jan 2001 20:28:33 +0000 (UCT) Subject: Closure? In-Reply-To: <3.0.5.32.20010129144016.00aa6c40@pobox3.genuity.com> from "J. Scott Marcus" at Jan 29, 2001 02:40:16 PM Message-ID: <200101292028.UAA20622@vacation.karoshi.com> > > At 15:09 01/26/2001 -0500, Marc Blanchet wrote: > > >> Bill Manning wrote: > >> Unless a viable counter proposal or modification to the existing > >>IAB/IESG proposal that has been accepted by RIPE and APNIC, I'm going > >>to recommend to the ARIN council that silence is consent and ARIN should > >>adopt the IAB/IESG proposal for a /48 being the default delegation size, > > > >for any organisation. (obvious but just want to make sure...) > > > Note quite. As I understand it, Marc, a /48 would also be the standard > allocation for a _home_ connection, > > Cheers, > - Scott > Even better Scott. A careful reading of the recommendation supports my statement above that for IPv6, "a /48 being the default delegation size" does not discriminate "_home_ vs. _organization_"... its for any viable request. Now the requests must meet certain criteria before a delegation will be processed and that seems to disuade profligrate delegations from being made. A quick review of the online material seems to have a reasonable "barrier" to entry. --bill From smarcus at genuity.com Mon Jan 29 15:08:19 2001 From: smarcus at genuity.com (J. Scott Marcus) Date: Mon, 29 Jan 2001 15:08:19 -0500 Subject: Closure? In-Reply-To: <200101261614.QAA17345@vacation.karoshi.com> Message-ID: <3.0.5.32.20010129150819.008adb20@pobox3.genuity.com> At 16:14 01/26/2001 +0000, bmanning at vacation.karoshi.com wrote: > > This is to remind you that ARIN is still holding out on accepting the >IAB/IESG recommendations for inital IPv6 delegation/allocation sizes. There >was some lively discussion at the last mtg but the concerns generally came >down to... "this makes me nervous and I don't understand it all to well." >Yes, there are operational concerns but quite frankly, the number of people >in the ARIN region that are able/willing to explore IPv6 seems to be either >very small, not willing to share experiences, or are happy with the 6bone >delegations. ARIN has pretty much removed the barriers to entry with the >zero-cost delegation policy in place. > > Unless a viable counter proposal or modification to the existing >IAB/IESG proposal that has been accepted by RIPE and APNIC, I'm going >to recommend to the ARIN council that silence is consent and ARIN should >adopt the IAB/IESG proposal for a /48 being the default delegation size, >subject to review, based on operational experience. As you may recall, I was one of the people who spoke up after Brian's talk at our last Public Policy meeting. Actually, I support the IAB/IESG recommendation, in general. There are two aspects that trouble me, and I would like to see these made clear to the IAB and IESG: 1) the recommendation is too glib in a number of its assumptions (see below). 2) the IAB and IESG had jolly well better remember that, if we do this, there are few if any additional bits to be given away! As far as assumptions: The recommendation states that the allocation efficiency for the 45 usable high order bits needs to remain above 0.22 in order to provide a /48 to everyone expected to be on the planet in 2050, and that the telephone system already exceeds this. > - RFC 1715 defines an "H ratio" based on experience in address space > assignment in various networks. Applied to a 45 bit address space, > and projecting a world population of 10.7 billion by 2050 (see > http://www.popin.org/pop1998/), the required assignment efficiency > is log_10(1.07*10^10) / 45 = 0.22. This is less than the > efficiencies of telephone numbers and DECnetIV or IPv4 addresses > shown in RFC 1715, i.e., gives no grounds for concern. In fact, it probably IS plenty. But it is important to remember the implication: That addresses within the initial 45 usable bits will be assigned fairly densely. The H ratio for the RIGHTHAND 80 bits of the IPv6 address is approximately zero -- not a sustainable example for the LEFTHAND bits to follow. Some IPv6 proponents like to claim that the protocol could uniquely address every electron in the universe. It's important to remember that the EFFECTIVE capacity of IPv6 reflects only 45 bits of addressability. The other 83 have already been wasted by the current recommendations. Are the remaining 45 bits enough? Yes, probably. But we need to be honest with ourselves. > - We are highly confident in the validity of this analysis, based on > experience with IPv4 and several other address spaces, and on > extremely ambitious scaling goals for the Internet amounting to an > 80 bit address space *per person*. Even so, being acutely aware of > the history of under-estimating demand, we have reserved more than > 85% of the address space (i.e., the bulk of the space not under the > Aggregatable Global Unicast Address (TLA) format prefix). > Therefore, if the analysis does one day turn out to be wrong, our > successors will still have the option of imposing much more > restrictive allocation policies on the remaining 85%. If we reach this scenario within our childrens' lifetime, we will have failed. The assumption that this migration entails only the implementation of new allocation policies is flawed. Much of the deployed gear -- perhaps most of it -- will break if this happens. Again, the recommendation is probably workable. I am worried about the underlying overconfidence. My two cents, - Scott From bmanning at vacation.karoshi.com Mon Jan 29 15:47:38 2001 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Mon, 29 Jan 2001 20:47:38 +0000 (UCT) Subject: Closure? In-Reply-To: <3.0.5.32.20010129150819.008adb20@pobox3.genuity.com> from "J. Scott Marcus" at Jan 29, 2001 03:08:19 PM Message-ID: <200101292047.UAA20662@vacation.karoshi.com> > As you may recall, I was one of the people who spoke up after Brian's talk > at our last Public Policy meeting. Yup. > Actually, I support the IAB/IESG recommendation, in general. There are two > aspects that trouble me, and I would like to see these made clear to the > IAB and IESG: I think that they understand this. > > 1) the recommendation is too glib in a number of its assumptions (see below). > > 2) the IAB and IESG had jolly well better remember that, if we do this, > there are few if any additional bits to be given away! Yes, many assumptions were made, often by people who have had little (recent) operational experience. You've got to start somewhere. To counter... We "redesigned" IPv4 a couple of times during its life expectancy. I think that there is still enough "headroom" to fix the "bit exaustion" when we get further operational experience. > > - We are highly confident in the validity of this analysis, based on > > experience with IPv4 and several other address spaces, and on > > extremely ambitious scaling goals for the Internet amounting to an > > 80 bit address space *per person*. Even so, being acutely aware of > > the history of under-estimating demand, we have reserved more than > > 85% of the address space (i.e., the bulk of the space not under the > > Aggregatable Global Unicast Address (TLA) format prefix). > > Therefore, if the analysis does one day turn out to be wrong, our > > successors will still have the option of imposing much more > > restrictive allocation policies on the remaining 85%. > > If we reach this scenario within our childrens' lifetime, we will have failed. Then the developers of IPv4 failed. IPv6 should be such a success disaster... :) > The assumption that this migration entails only the implementation of new > allocation policies is flawed. Much of the deployed gear -- perhaps most > of it -- will break if this happens. Allow me to trot out a varient of O'Dells law. "The installed base is insignificant." > Again, the recommendation is probably workable. I am worried about the > underlying overconfidence. I agree, its a bit a the cheeky side but I can see how it can work and give us some room to stretch. Given that ARIN is the sole remaining holdout, it might be easier to kowtow now, with reservations noted and then collect enough empirical data to beat the I* senseless with their lack of operational vision. :) > My two cents, > - Scott --bill From smarcus at genuity.com Mon Jan 29 16:25:48 2001 From: smarcus at genuity.com (J. Scott Marcus) Date: Mon, 29 Jan 2001 16:25:48 -0500 Subject: Closure? In-Reply-To: <200101292047.UAA20662@vacation.karoshi.com> References: <3.0.5.32.20010129150819.008adb20@pobox3.genuity.com> Message-ID: <3.0.5.32.20010129162548.02d58100@pobox3.genuity.com> >> ... If we reach this scenario within our childrens' lifetime, we will have failed. > > Then the developers of IPv4 failed. IPv6 should be such a > success disaster... :) They DID fail, at least in this respect. They could have made the address space larger, as did the designers of XNS. But it was early days, and it was hard to see how the Internet was going to grow. At this point, we KNOW that it's going to be whopping big. We do not have the same excuse. By the time IPv6 exhausts, it will be deeply embedded into countless devices, and into the fabric of our society itself. >> The assumption that this migration entails only the implementation of new >> allocation policies is flawed. Much of the deployed gear -- perhaps most >> of it -- will break if this happens. > > Allow me to trot out a varient of O'Dells law. > "The installed base is insignificant." By the time we exhaust IPv6 space, the rate of growth will be much lower, probably single digit percentage points per year. In any case, the installed base is clearly paramount -- consider the economics of network externalities. That's why there are such strong first mover effects in this industry. And that's why it has been so difficult to deploy IPv6 in the first place. >> Again, the recommendation is probably workable. I am worried about the >> underlying overconfidence. > > I agree, its a bit a the cheeky side but I can see how it can > work and give us some room to stretch. Given that ARIN is the sole > remaining holdout, it might be easier to kowtow now, with reservations > noted and then collect enough empirical data to beat the I* senseless > with their lack of operational vision. :) ... so at the end of the day, we agree. I don't see this as a question of kowtowing. If I thought their recommendation were unworkable, I would be perfectly happy to be the only standout. As it is, I think that it's good enough. We can move forward with it "with reservations noted". From brian at hursley.ibm.com Mon Jan 29 17:00:53 2001 From: brian at hursley.ibm.com (Brian E Carpenter) Date: Mon, 29 Jan 2001 16:00:53 -0600 Subject: Closure? References: <3.0.5.32.20010129150819.008adb20@pobox3.genuity.com> Message-ID: <3A75E815.CB1C16D5@hursley.ibm.com> "J. Scott Marcus" wrote: ... > As you may recall, I was one of the people who spoke up after Brian's talk > at our last Public Policy meeting. > > Actually, I support the IAB/IESG recommendation, in general. There are two > aspects that trouble me, and I would like to see these made clear to the > IAB and IESG: > > 1) the recommendation is too glib in a number of its assumptions (see below). You know, I don't think the frame of mind was glib when we wrote it. Personally, I thought long and hard about the question of whether we were repeating the error of the orginal 8+24 layout of IPv4 addresses or the 3 class model (you could argue that we would be in much less trouble today if addresses had been classless from the start, but let's not go down that rathole). But then I ran the numbers and saw that they are really, really big numbers. I honestly don't think that is glib. > > 2) the IAB and IESG had jolly well better remember that, if we do this, > there are few if any additional bits to be given away! True. > > As far as assumptions: The recommendation states that the allocation > efficiency for the 45 usable high order bits needs to remain above 0.22 in > order to provide a /48 to everyone expected to be on the planet in 2050, > and that the telephone system already exceeds this. > > > - RFC 1715 defines an "H ratio" based on experience in address space > > assignment in various networks. Applied to a 45 bit address space, > > and projecting a world population of 10.7 billion by 2050 (see > > http://www.popin.org/pop1998/), the required assignment efficiency > > is log_10(1.07*10^10) / 45 = 0.22. This is less than the > > efficiencies of telephone numbers and DECnetIV or IPv4 addresses > > shown in RFC 1715, i.e., gives no grounds for concern. > > In fact, it probably IS plenty. But it is important to remember the > implication: That addresses within the initial 45 usable bits will be > assigned fairly densely. The H ratio for the RIGHTHAND 80 bits of the IPv6 > address is approximately zero -- not a sustainable example for the LEFTHAND > bits to follow. Absolutely correct. Sparse assignments would be a mistake. Do you think this should be stated somehow? Send words... > > Some IPv6 proponents like to claim that the protocol could uniquely address > every electron in the universe. It's important to remember that the > EFFECTIVE capacity of IPv6 reflects only 45 bits of addressability. The > other 83 have already been wasted by the current recommendations. Well, it's not quite that bad - as you observe, some subscribers will actually get /64s and even they could run a single level of LAN - and some of the /48's will be used by pretty large corporate networks. But I agree, the electrons argument is a bit silly. > > Are the remaining 45 bits enough? Yes, probably. But we need to be honest > with ourselves. > > > - We are highly confident in the validity of this analysis, based on > > experience with IPv4 and several other address spaces, and on > > extremely ambitious scaling goals for the Internet amounting to an > > 80 bit address space *per person*. Even so, being acutely aware of > > the history of under-estimating demand, we have reserved more than > > 85% of the address space (i.e., the bulk of the space not under the > > Aggregatable Global Unicast Address (TLA) format prefix). > > Therefore, if the analysis does one day turn out to be wrong, our > > successors will still have the option of imposing much more > > restrictive allocation policies on the remaining 85%. > > If we reach this scenario within our childrens' lifetime, we will have failed. Agreed. This really isn't what we expect. > > The assumption that this migration entails only the implementation of new > allocation policies is flawed. Much of the deployed gear -- perhaps most > of it -- will break if this happens. Well, we could argue that point. If people do clean implementations it shouldn't be the case. But sloppy implementations are another question. > > Again, the recommendation is probably workable. I am worried about the > underlying overconfidence. If there is that tone in the text, it should be trimmed out. Brian From shane at ripe.net Tue Jan 30 04:35:30 2001 From: shane at ripe.net (Shane Kerr) Date: Tue, 30 Jan 2001 10:35:30 +0100 (CET) Subject: Closure? In-Reply-To: <3.0.5.32.20010129150819.008adb20@pobox3.genuity.com> Message-ID: On Mon, 29 Jan 2001, J. Scott Marcus wrote: > Again, the recommendation is probably workable. I am worried about > the underlying overconfidence. This is my position as well. Actually, I am worried by both the overconfidence and the apparent classfulness and inflexibility of IPv6. We've started with 128 bits, threw away half, split the rest up on 16-bit boundaries and now we're left with 13 bits to play with all of a sudden. The analysis that "well, it's only 1/8 of the available space" is fundamentally flawed, because problems with allocation of that first block may impact the use of the rest of the space. IPv6 folks at the IETF think that people who disagree with their recommendation simply don't understand it - not true! I, at least, simply disagree. The "broad concensus and acceptance" within other RIR communities is probably a combination of eagerness to roll out new networks and excessive trust in the IETF recommendation, rather than a well-thought out assessment of possible problems. But let's be realistic. It doesn't really matter WHAT the RIR space usage recommendations are. If I get a /35 from APNIC, ARIN, or the RIPE NCC, then if I'm at all smart about my allocations, then I won't ever need more space. There's no reason for me to allocate /48, /64, or any other specific allocation. Unless the RIR's decide to monitor allocations and REVOKE IPv6 space, any recommendation will carry even less weight than TTL suggestions for DNS servers (I was going to say something about recommendations to put name servers on seperate networks, but that would be an unfair jab at a certain well-known company, I suppose...). Shane From smarcus at genuity.com Tue Jan 30 09:06:21 2001 From: smarcus at genuity.com (J. Scott Marcus) Date: Tue, 30 Jan 2001 09:06:21 -0500 Subject: Closure? In-Reply-To: <3A75E815.CB1C16D5@hursley.ibm.com> References: <3.0.5.32.20010129150819.008adb20@pobox3.genuity.com> Message-ID: <3.0.5.32.20010130090621.008c47a0@pobox3.genuity.com> Thanks, Brian! This is a very helpful response. I responded to just a couple of your points, as we seem to be largely in agreement on the others. >> 2) the IAB and IESG had jolly well better remember that, if we do this, >> there are few if any additional bits to be given away! > >True. I would propose that the recommendation be amended to note this explicitly -- I propose verbiage below. >> As far as assumptions: The recommendation states that the allocation >> efficiency for the 45 usable high order bits needs to remain above 0.22 in >> order to provide a /48 to everyone expected to be on the planet in 2050, >> and that the telephone system already exceeds this. >> >> > - RFC 1715 defines an "H ratio" based on experience in address space >> > assignment in various networks. Applied to a 45 bit address space, >> > and projecting a world population of 10.7 billion by 2050 (see >> > http://www.popin.org/pop1998/), the required assignment efficiency >> > is log_10(1.07*10^10) / 45 = 0.22. This is less than the >> > efficiencies of telephone numbers and DECnetIV or IPv4 addresses >> > shown in RFC 1715, i.e., gives no grounds for concern. >> >> In fact, it probably IS plenty. But it is important to remember the >> implication: That addresses within the initial 45 usable bits will be >> assigned fairly densely. The H ratio for the RIGHTHAND 80 bits of the IPv6 >> address is approximately zero -- not a sustainable example for the LEFTHAND >> bits to follow. > >Absolutely correct. Sparse assignments would be a mistake. Do you think >this should be stated somehow? Send words... What about taking the paragraph that begins with "RFC 1715" and changing it to end: "gives no grounds for concern provided that the RIRs allocate /48's prudently, and that the IAB/IESG refrain from any new recommendations that might further reduce the remaining 45 variable bits unless a compelling requirement emerges." It makes for a long sentence -- perhaps we could re-wordsmith. But you get the idea. We should not underestimate our ability to squander the remaining bits. >> The assumption that this migration entails only the implementation of new >> allocation policies is flawed. Much of the deployed gear -- perhaps most >> of it -- will break if this happens. > >Well, we could argue that point. If people do clean implementations it shouldn't >be the case. But sloppy implementations are another question. I think that the temptation to take advantage of the fixed bit boundaries to simplify code and configuration will be irresistable. But even if all implementations envisioned in advance that a new and unspecified partition of the bits might emerge in the future -- somehow? -- the quality of that code in implementations in the field would be unknown until proven. Sort of a Y2K problem all over again. And that's in the best of circumstances. What about tacking a sentence onto the next paragraph (the "We are highly confident" paragraph) to say something like: "Such a migration may not be devoid of pain, but it should be far less disruptive than deployment of a new version of IP."? >> Again, the recommendation is probably workable. I am worried about the >> underlying overconfidence. > >If there is that tone in the text, it should be trimmed out. I very much appreciate your invitation. :-) The two areas above are the ones that bothered me, and I have availed myself of the opportunity to propose new text. Does anybody else have strong opinions? Cheers, - Scott From huberman at gblx.net Tue Jan 30 10:26:32 2001 From: huberman at gblx.net (David R Huberman) Date: Tue, 30 Jan 2001 08:26:32 -0700 (MST) Subject: Closure? Message-ID: Global Crossing supports the ARIN Advisory Council endorsing the IESG/IAB recommendation for v6 assignments with or without the discussed text changes. /david *--------------------------------* | Global Crossing IP Engineering | | Manager, Global IP Addressing | | TEL: (908) 720-6182 | | FAX: (703) 464-0802 | *--------------------------------*