RE: Meeting logistics cost, convenience and risk and RE Deja Vu
I have been reading these many excellent points for eleven days now. However, I note that similar discussions occur after most IETFs. My own preference is that these conversations not occur, since their (almost predictable) recurrence suggests that this is more "venting" than "problem solving", and I'd prefer my mailbox to fill up with material that I can do something about. I therefore suggest that we either discontinue these many threads or else we establish something like POISED to actually do something to scratch these nagging itches. Should we establish a POISED-like discussion, then I would like to introduce the following data points: 1) A coworker of mine is the IEEE Secretary. I've overhead enough of his phone calls to know that IEEE meetings and logistics are scheduled three to five years in advance. 2) The community needs to determine whether fixed locations or variable locations are preferable. Arguments for both alternatives can be made. However, the answer to this question will fundamentally shape the rest of the discussion. 3) The fundamental requirements of any IETF meeting include (increasingly large and increasingly numerous) meeting rooms, extensive terminal facilities with both IPv4 and (increasingly) IPv6 connectivity, excellent wireless connectivity, proximity to many hotels, proximity to many restaurants. It is also desirable that the location have proximity to major airport hub locations. 4) Capabilities for "virtual attendance" need to be enhanced. Remote attendees need to be able to contribute to meetings and respect needs to be shown to them by consistently using microphones. More sessions should also have facilities to enable "virtual attendance". 5) I suggest that historic meeting demographic information be used to determine where the majority of attendees come from. This demographic information should also consider where the majority of IDs and RFC authors reside. I acknowledge arguments to the contrary, however, it is my personal perspective that for the sake of continuity (which I argue is increasingly important within the IETF as it continues to grow), locations favoring continued attendance of this majority are preferable over locations encouraging attendance by new classes of attendees.
RE: [midcom] WG scope/deliverables
Taking your valuable points a bit further, NAT avoidance arguments aren't likely to sell IPv6 to us large end users, because this is a problem for which it is difficult to construct a business case that will excite the non-technical managers who are in charge of blessing large capital expenses. By contrast, what will sell IPv6 will be "Killer Applications" that require IPv6. I am optimistic that advances like the UMTS Release 2000 Cell Phone standard, which requires IPv6, will provide the impetus for us end users to eventually justify the expenses of an IPv6 deployment. Should that business case be made, then 6to4 can ease this newer infrastructure into our systems. Once that occurs, then the advantages of a NAT-less IPv6 would become relevant to us large corporations. As it is, this is a theoretical concern at best to us due to the real-life implications (time, $$$) of deploying IPv6 into our networks compared to the advantages of cheaper stop-gap "solutions" like NATs. By saying this, I don't want to imply that I have any technical disagreement with the arguments that have led many to conclude that "NATs are evil." I am only stating that such arguments alone don't make a good business case. Similarly, while the best current approximations that the H-ratio, which determines when the IPv4 Address Space will be saturated for all practical purposes, will most likely occur in 2002 (i.e., NEXT YEAR) motivates me as a technical person, conveying these concerns into a viable business case that will motivate the "guys with the bucks" is a very different proposition indeed. That is why we need the "escape hatch" which midcom will hopefully provide us with, especially in view of the difficulties which current NAT approaches will introduce as we increasingly deploy peer-to-peer applications within our infrastructures. -Original Message- From: Brian E Carpenter [mailto:[EMAIL PROTECTED]] Sent: Friday, February 16, 2001 8:04 AM To: Bernard Aboba Cc: Randy Bush; Melinda Shore; Michael W. Condry; [EMAIL PROTECTED] Subject: Re: [midcom] WG scope/deliverables Bernard, Exactly. That is why 6to4 came out the way it did - it offers a way for a NATted IPv4 site to introduce non-NATted IPv6 without losing anything or throwing away anything. There are RFCs explaining the issues with NAT technically and objectively. I don't see why this generates comments about anti-NAT religion. It's obvious when you read those RFCs and think about P2P computing that NAT is a problem. If we don't avoid that problem in IPv6 we will have failed as engineers. Brian Bernard Aboba wrote: i suggest that, for most of us, there are more useful and concrete major direct goals of ipv6 than anti-nat religion. And in fact, the anti-NAT religion hurts deployment of IPv6 because it is hard to get customers to throw away things they have already bought. I would also suggest that the rapidity at which NAT is being deployed for IPv4 suggests that we need to think about how to deploy IPv6 in an environment where IPv4 NATs are prevalent. Thus, it is unlikely that IPv6 will displace IPv4 NATs; tather it will augment them.
RE: [midcom] WG scope/deliverables
Would such a rendezvous service work if their were NATs between each of the participants and the service itself (regardless of whether it is hosted on a NAT or not)? If so, wouldn't such a solution alter peer-to-peer to become a hub-and-spoke service requiring ISP mediation in the Internet case as opposed to peer-to-peer? -Original Message- From: David T. Perkins [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 31, 2001 3:41 PM To: Michael Richardson; [EMAIL PROTECTED] Subject: Re: [midcom] WG scope/deliverables HI, On the list below, I believe that peer-to-peer applications like napster can work in a NAT world. All you need is a registration and rendezvous service to put the two peers together. This can be part of the box that also provides the NAT service. At 05:54 PM 1/31/2001 -0500, Michael Richardson wrote: NAT's work for web surfing. No dispute here. NAT's make the Internet into TV. NAT's suck for napster-type applications. It was napster like (e.g. peer-to-peer) things that made the Internet popular. Based upon some data on "web ready cell phones" being used primarily to send text messages (e.g. do "peer-to-peer" type things), I'd say that the love for NATs will very soon decline. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson Regards, /david t. perkins
