Weekly posting summary for ietf@ietf.org
Total of 151 messages in the last 7 days. script run at: Fri Aug 3 00:53:01 EDT 2007 Messages | Bytes| Who +--++--+ 5.30% |8 | 9.67% |90709 | [EMAIL PROTECTED] 6.62% | 10 | 5.54% |52016 | [EMAIL PROTECTED] 5.30% |8 | 5.06% |47445 | [EMAIL PROTECTED] 2.65% |4 | 6.59% |61857 | [EMAIL PROTECTED] 3.31% |5 | 3.43% |32181 | [EMAIL PROTECTED] 3.31% |5 | 3.42% |32072 | [EMAIL PROTECTED] 3.31% |5 | 2.64% |24738 | [EMAIL PROTECTED] 2.65% |4 | 2.43% |22809 | [EMAIL PROTECTED] 2.65% |4 | 2.28% |21378 | [EMAIL PROTECTED] 2.65% |4 | 2.18% |20491 | [EMAIL PROTECTED] 2.65% |4 | 1.96% |18406 | [EMAIL PROTECTED] 0.66% |1 | 3.86% |36180 | [EMAIL PROTECTED] 2.65% |4 | 1.60% |15034 | [EMAIL PROTECTED] 1.99% |3 | 2.21% |20785 | [EMAIL PROTECTED] 1.99% |3 | 1.97% |18532 | [EMAIL PROTECTED] 1.99% |3 | 1.87% |17595 | [EMAIL PROTECTED] 1.99% |3 | 1.79% |16843 | [EMAIL PROTECTED] 1.99% |3 | 1.37% |12856 | [EMAIL PROTECTED] 1.99% |3 | 1.36% |12722 | [EMAIL PROTECTED] 1.99% |3 | 1.35% |12629 | [EMAIL PROTECTED] 1.32% |2 | 1.97% |18498 | [EMAIL PROTECTED] 1.32% |2 | 1.46% |13695 | [EMAIL PROTECTED] 1.32% |2 | 1.33% |12457 | [EMAIL PROTECTED] 1.32% |2 | 1.19% |11178 | [EMAIL PROTECTED] 1.32% |2 | 1.05% | 9821 | [EMAIL PROTECTED] 1.32% |2 | 1.01% | 9494 | [EMAIL PROTECTED] 1.32% |2 | 1.01% | 9478 | [EMAIL PROTECTED] 1.32% |2 | 0.94% | 8788 | [EMAIL PROTECTED] 1.32% |2 | 0.92% | 8591 | [EMAIL PROTECTED] 1.32% |2 | 0.89% | 8395 | [EMAIL PROTECTED] 0.66% |1 | 1.18% |5 | [EMAIL PROTECTED] 0.66% |1 | 0.87% | 8208 | [EMAIL PROTECTED] 0.66% |1 | 0.79% | 7416 | [EMAIL PROTECTED] 0.66% |1 | 0.78% | 7348 | [EMAIL PROTECTED] 0.66% |1 | 0.74% | 6987 | [EMAIL PROTECTED] 0.66% |1 | 0.72% | 6758 | [EMAIL PROTECTED] 0.66% |1 | 0.71% | 6653 | [EMAIL PROTECTED] 0.66% |1 | 0.69% | 6519 | [EMAIL PROTECTED] 0.66% |1 | 0.69% | 6507 | [EMAIL PROTECTED] 0.66% |1 | 0.69% | 6445 | [EMAIL PROTECTED] 0.66% |1 | 0.67% | 6334 | [EMAIL PROTECTED] 0.66% |1 | 0.67% | 6303 | [EMAIL PROTECTED] 0.66% |1 | 0.67% | 6269 | [EMAIL PROTECTED] 0.66% |1 | 0.66% | 6187 | [EMAIL PROTECTED] 0.66% |1 | 0.64% | 5996 | [EMAIL PROTECTED] 0.66% |1 | 0.62% | 5806 | [EMAIL PROTECTED] 0.66% |1 | 0.61% | 5709 | [EMAIL PROTECTED] 0.66% |1 | 0.60% | 5631 | [EMAIL PROTECTED] 0.66% |1 | 0.60% | 5626 | [EMAIL PROTECTED] 0.66% |1 | 0.57% | 5376 | [EMAIL PROTECTED] 0.66% |1 | 0.56% | 5225 | [EMAIL PROTECTED] 0.66% |1 | 0.55% | 5190 | [EMAIL PROTECTED] 0.66% |1 | 0.55% | 5146 | [EMAIL PROTECTED] 0.66% |1 | 0.54% | 5062 | [EMAIL PROTECTED] 0.66% |1 | 0.52% | 4914 | [EMAIL PROTECTED] 0.66% |1 | 0.52% | 4911 | [EMAIL PROTECTED] 0.66% |1 | 0.52% | 4905 | [EMAIL PROTECTED] 0.66% |1 | 0.51% | 4771 | [EMAIL PROTECTED] 0.66% |1 | 0.50% | 4701 | [EMAIL PROTECTED] 0.66% |1 | 0.50% | 4684 | [EMAIL PROTECTED] 0.66% |1 | 0.50% | 4682 | [EMAIL PROTECTED] 0.66% |1 | 0.48% | 4477 | [EMAIL PROTECTED] 0.66% |1 | 0.47% | 4379 | [EMAIL PROTECTED] 0.66% |1 | 0.46% | 4318 | [EMAIL PROTECTED] 0.66% |1 | 0.46% | 4282 | [EMAIL PROTECTED] 0.66% |1 | 0.45% | 4227 | [EMAIL PROTECTED] 0.66% |1 | 0.44% | 4125 | [EMAIL PROTECTED] 0.66% |1 | 0.44% | 4123 | [EMAIL PROTECTED] 0.66% |1 | 0.43% | 4075 | [EMAIL PROTECTED] 0.66% |1 | 0.43% | 4052 | [EMAIL PROTECTED] 0.66% |1 | 0.42% | 3942 | [EMAIL PROTECTED] 0.66% |1 | 0.41% | 3867 | [EMAIL PROTECTED] 0.66% |1 | 0.41% | 3807 | [EMAIL PROTECTED] 0.66% |1 | 0.39% | 3702 | [EMAIL PROTECTED] +--++--+ 100.00% | 151 |100.00% | 938433 | Total ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4
> NAT isn't the only answer to the question "I can't get IPv4 addresses, > what do I do?" Using IPv6 and a proxy to reach the IPv4 world is much, > much cleaner. And it also works from v4 to v6. We really should start > advocating this as the preferred transition mechanism. NAT and proxies are not mutually exclusive. There are advantages to having a proxy that can forward TCP and UDP traffic from an outside address/port to an inside address/port and vice versa; there are also advantages to a NAT that can do the same thing on a per-packet level. But a good, explicit protocol and API for doing each would be welcome. It would also be useful if the forwarder/NAT had explicit means of communicating the "external" source and destination address/port to the "internal" host - say via the same control protocol used to establish and maintain the address binding. That would make it relatively easy to, say, have a server inside an IPv6-only network establish presence on an IPv4 network provided by an ISP, while still allowing the application to see the real IPv4 source address (say for logging or spam filtering). The main thing is to avoid having "transparent NAT" - i.e. NATs that automatically establish address bindings and start forwarding packets - in IPv6. A lot of where NAT bites is when it tries to second-guess what the application is doing. (that goes double for DNS ALG). I'm not nearly so worried about IPv4-to-IPv6 NATs when the applications are explicitly aware of the NAT and explicitly manage the binding, and where the NAT doesn't try to muck with DNS. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4
On Aug 2, 2007, at 4:27 PM, Iljitsch van Beijnum wrote: NAT isn't the only answer to the question "I can't get IPv4 addresses, what do I do?" Using IPv6 and a proxy to reach the IPv4 world is much, much cleaner. And it also works from v4 to v6. We really should start advocating this as the preferred transition mechanism. It seems you both are in agreement. Wouldn't a proxy for reaching IPv4 represent Philip's State B? A) Has at least one full IPv4 address plus an IPv6 /64. B) Has a share in a NAT-ed IPv4 addesss plus an IPv6 /64. C) Has at least one full IPv4 address D) Has a share in a NAT-ed IPv4 address Such a topology must offer a means to declare the transitions between IPv6 and IPv4. Perhaps the HIP WG may offer a popular method to navigate within the growing complexity. Could SSH, LDAP, and a dynamic DNS server within a commodity residential access point represent a solution as well? This might introduce an era where rapid routing changes becomes the norm, and where most network connection are expected to use TLS or SSH tunneling. These highly extensible protocols are within the capability of today's microprocessors in commodity products. -Doug ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4
On 3-aug-2007, at 0:46, Hallam-Baker, Phillip wrote: I expect the market in IPv4 addresses to trace the following pattern If you would have cared to quote properly and thus read the previous message you'd have seen that ARIN doesn't want to allow an address market. Since they are the ones administering 1.5 billion of the 2.5 billion addresses given out, including the legacy class A space, not much is going to happen without their cooperation. (But note that the US is at about 35% of the addresses it used up last year right now, while China is at 110%. This will be the first year that China and not the US is the largest user of address space.) For the purpose of the rest of the discussion, please realize that around 90% of the requests is satisfied with 10% of the address space used per year and the other way around. I.e., 90% of all address space is going to a fairly small number of large ISPs. Phase 1: Anticipation As the exhaustion in IPv4 address space nears there will be increasing speculative acquisition of IPv4 address allocations. The only people who can successfully request enough address space to make a difference are the people who have been doing large requests before. So the address space is going to end up with the large ISPs regardless whether they play nice or try to get as much as possible before supplies run out. Phase 2: Confusion The immeditate reaction to exhaustion of the address space will be recriminations countered by 'I told you so'. Parties with excess IPv4 capacity will investigate options for sale. It will be interesting to see what ARIN does if (for instance) HP tries to sell 30 million addresses. I don't think ARIN can let that happen and I don't think that HP has a good case in court if ARIN subsequently takes the addresses. (If they were going to sell them obviously they didn't need them.) What are the precedents here with phone number and address renumbering? Phase 3: Speculation You forget that the only people who'll have trouble are those that need NEW address space. That's a relatively small percentage of the internet community at any given time. And 90% of them can be served from address space that is returned every year. (This can be 10+ million addresses per year.) Phase 4: Asset Stripping Large ISPs begin to exceed their existing IPv4 stock. They discover that it is cheaper to buy a smaller ISP for its stock of excess IPv4 address space than to buy from an IPv4 speculator. Only if you need relatively few addresses. Phase 5: Bubble bursts Second round of I-told-you-sos as we welcome large numbers of people on IPv6. Sweet! It is in the strategic interests of ISPs to deploy not just any hyper-NAT but a hyperNAT that drives to deployment of IPv6 and minimize the length of the crisis phase. If they acted soon enough it might even be possible to avoid the buble phase entirely. NAT isn't the only answer to the question "I can't get IPv4 addresses, what do I do?" Using IPv6 and a proxy to reach the IPv4 world is much, much cleaner. And it also works from v4 to v6. We really should start advocating this as the preferred transition mechanism. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IPv4
Are we certain that an IP address is not property? We can state that it is not the case but such statements do not necessarily have the intended effect. The only way to be sure would be to do something silly and see what the result of the lawsuit is. For example we could decide to cancel the allocation for net 18. Jeff Schiller would have the injunction delivered a few hours later and after eight to twelve years of littigation we would have an answer. In the meantime net 18 could be considered property for all practical purposes since regardless of the outcome we do not anticipate that an IPv4 address will have a significant scarcity premium in 2015. I do not think that the conditions are met for an efficient market in IPv4 address space. There is not sufficient liquidity for a start and the constraints on supply are distinctly odd. All it takes to assign IPv4 address assignments is for someone to publish the BGP adverts and for others to accept them. Returning to the previous thought experiment, if the assignment body that originally allocated net 18 attempts to withdraw it then its time for lawyers at 20 paces. If on the other hand the net community decides to recognize another source of authority and direct net 18 traffic elsewhere I don't see where the cause of action lands. There are certainly cases where this type of issue could occur. If the assignment bodies decided to price gouge for address block allocations to buy themselves a personal yatch for example. What we have to avoid losing sight of here is that the objective is to deploy IPv6, an environment where technical scarcity of addresses is simply not an issue. The only scarcity that can exist is if we are negligent in the allocation procedures. As I said at the plenary, don't worry too much about the state we leave the IPv4 world. The IPv4 world will go away when people stop exchanging IPv4 routes. I don't expect that to happen until 2025-2030, but that is the objective here. I don't expect people to ever stop routing IPv4 packets on private nets. There are still people who route UUCP. We need to think in terms of how we establish strategic interests that 1) Encourage transition to the prefered end state (pure IPv6) 2) Minimize inconvenience to and maximize functionality for all parties during transition 3) Minimize the cost to all parties 4) Align costs of transition with benefits During the later stages of transition we will be in a state where there are vastly more Internet hosts than IPv4 addresses. At least a hundred billion hosts, quite likely a trillion or more. Many of those hosts will not require IPv4 connectivity. Light switches for example. But most hosts will need a limited IPv4 connection capability. That is where hyper-NAT will come in. What the devices require is some quantity of IPv4 ports, not an IPv4 address. By 2015 the IPv4 address space is going to be heavily NAT-ed. The only way that 5 billion people can use 4 billion addresses is if a substantial number of people share. There will thus be the following classes of broadband internet user: A) Has at least one full IPv4 address plus an IPv6 /64. B) Has a share in a NAT-ed IPv4 addesss plus an IPv6 /64. C) Has at least one full IPv4 address D) Has a share in a NAT-ed IPv4 address Note that the total number of users in class A and C combined cannot ever be more than four billion and in practice is highly unlikely to exceed two billion. We have got as far as we have to date because dial-up users are in effect time-sharing their IPv4 address allocation. The 'always on' property of broadband means that this form of sharing will inevitably decline. My big concern here is that the rejectionism I see with respect to NAT in the IPv6 community is driving the market from state C into state D, the worst possible state. We have to engineer a situation where the market forces encourage a transition to state B. It is not possible for every Internet user to end up in state A unless the growth of Internet use suddenly stops. I expect the market in IPv4 addresses to trace the following pattern Phase 1: Anticipation As the exhaustion in IPv4 address space nears there will be increasing speculative acquisition of IPv4 address allocations. Within a few years a point will be reached where the anticipated resale value of an IPv4 address exceeds the cost of holding it as inventory. At this point the entire remaining stock of IPv4 will be purchased by IP address squatters. Phase 2: Confusion The immeditate reaction to exhaustion of the address space will be recriminations countered by 'I told you so'. Parties with excess IPv4 capacity will investigate options for sale. Phase 3: Speculation Despite the large number of IPv4 addresses the technical difficulty of transfer creates liquidity issues. As with certain commodity markets (e.g. Palladium during the cold fusion bubble) the price rises to a poin
Re: DHCP failures
> "Iljitsch" == Iljitsch van Beijnum <[EMAIL PROTECTED]> writes: Iljitsch> On 2-aug-2007, at 21:17, Dave Crocker wrote: >>> It was also interesting to open the Mac network control >>> pannel, enable my Airport (WLAN) interface, and see the IPv6 >>> global address appear almost instantaneously and in many case >>> having to wait many seconds to minutes for DHCP provided IPv4 >>> address to appear. >> Any chance this was merely due to a difference in scaling, with >> IPv4 DHCP usage being large-scale and IPv6 being small? >> I suppose the more constructive way to ask this is: Does anyone >> know why one worked better than the other? Iljitsch> I don't think there was any IPv6 DHCP, and if there was, Iljitsch> most hosts wouldn't have used it because they don't Iljitsch> implement it. The advantage of stateless autoconf over Iljitsch> DHCP is that with stateless autoconf, a singe router Iljitsch> advertisement multicast to all IPv6 hosts can provide an Iljitsch> unlimited number of hosts with address information (the Iljitsch> hosts still need to do duplicate address detection, but Iljitsch> since no reply means success it's hard to fail here) so Iljitsch> it's eminently more scalable than DHCP. Let's be clear here. The scaling properties of stateless autoconf are better than DHCP in cases where I want to give a uniform configuration to all nodes on the link and where all the configuration I want to hand out is supported by stateless autoconf. Issues such as giving hosts hostnames, dynamic dns updates, etc can change to the scalining properties of the entire IPV6 configuration experience to be different than the base scaling properties of stateless autoconf. --Sam ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCP failures (was RE: Do you want to have more meetings outside US ?)
On 2-aug-2007, at 21:17, Dave Crocker wrote: It was also interesting to open the Mac network control pannel, enable my Airport (WLAN) interface, and see the IPv6 global address appear almost instantaneously and in many case having to wait many seconds to minutes for DHCP provided IPv4 address to appear. Any chance this was merely due to a difference in scaling, with IPv4 DHCP usage being large-scale and IPv6 being small? I suppose the more constructive way to ask this is: Does anyone know why one worked better than the other? I don't think there was any IPv6 DHCP, and if there was, most hosts wouldn't have used it because they don't implement it. The advantage of stateless autoconf over DHCP is that with stateless autoconf, a singe router advertisement multicast to all IPv6 hosts can provide an unlimited number of hosts with address information (the hosts still need to do duplicate address detection, but since no reply means success it's hard to fail here) so it's eminently more scalable than DHCP. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DHCP failures (was RE: Do you want to have more meetings outside US ?)
Bob Hinden wrote: It was also interesting to open the Mac network control pannel, enable my Airport (WLAN) interface, and see the IPv6 global address appear almost instantaneously and in many case having to wait many seconds to minutes for DHCP provided IPv4 address to appear. Any chance this was merely due to a difference in scaling, with IPv4 DHCP usage being large-scale and IPv6 being small? I suppose the more constructive way to ask this is: Does anyone know why one worked better than the other? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
Brian E Carpenter wrote: 1. The fact that the network is expected to be shaken down within hours instead of progressively over some large number of days. It goes from small scale test to full load in about 24 hours. That argues for re-using venues known to work well and, of course, keeping the rest of the technical and operations details as stable as possible. (Yeah, some change is required, over time, and any change carries some risk.) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: on the value of "running code" (was Re: Do you want to have more meetings outside US ?)
> yes! > I tried to resist the 47th rehash of this thread, but... too late... > > Within a commercial environment, the organization has to be > fairly convinced that their better mousetrap is going to work, > in order to fund it, productize it, document it, sell it, and support it. > > This process will always find more bugs in the mousetrap than > simply documenting it and skipping all the other steps. > > If a vendor bothers to do all this, and multiple IETFers can say in a BoF > that they have used the mousetrap and it really does work, > that is worth a whole lot more than "I read the draft and > it looks pretty good". yes. but then again, vendors are insensitive to certain kinds of bugs. the myriad bugs produced by introduction of NAT are good examples. a little bit of analysis should have convinced any responsible vendor to either not sell NAT products, or to be honest in marketing them and to accompany them with rather strong disclaimers. (not to attack NATs specifically, they're just the most obvious of many examples and the easiest ones to cite) > There is a certain amount of healthy risk that the IESG > can take when chartering new standards-track work. > Prior implementations should not be a gating factor, but > it makes their decision much easier when there is objective > evidence the mousetrap actually works and it is already being > used by the industry. again, being used by the industry is no indicator of soundness. and being used by the industry in the absence of public protocol review is highly correlated with poor design. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: DHCP failures (was RE: Do you want to have more meetingsoutside US ?)
The metric system has been legal in the US since 1895 when the US agreed to "adopt" it in exchange for France agreeing to Greenwich, England, for the Prime Meridian. Donald -Original Message- From: Douglas Otis [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2007 2:17 PM To: John C Klensin Cc: Iljitsch van Beijnum; ietf@ietf.org; [EMAIL PROTECTED] Subject: Re: DHCP failures (was RE: Do you want to have more meetingsoutside US ?) On Jul 31, 2007, at 6:30 PM, John C Klensin wrote: > And, while I'm picking on DHCP because I personally had more > problems with it, I see IPv6 authconfig as being exactly the same > issue: we are telling the world that these things work and they > should be using them; if we can't make them work for our own > meetings... Whether one regards IPv6 as "ready for prime-time" depends upon location. IPv6 appears to represent a metric measurement in the only industrially developed nation, despite a 1975 act of Congress, still is using fahrenheit, ounce, pound, inch, feet, and mile. There will always be problems offering an excuse not to adopt change, even when the rest of world has. Oddly, a 2x4 is neither, but might be required to promote change. -Doug ___ 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: on the value of "running code" (was Re: Do you want to have more meetings outside US ?)
David Conrad wrote: I'd offer that the OSI protocol stack was probably significantly more reviewed than the TCP/IP stack. Depends what you mean by "more reviewed". More eyes looking at the specs? Probably yes. More critical analysis by senior technical architects? Probably not. > At the very least, running code is an empirical proof that an > architecture _can_ work. Again, depends upon what one means by running code. Certainly there were early prototypes of OSI modules, and even running products. Clearly, that was not enough. In contrast, the Internet code was deployed and used in a running service, with increasing scale. So the distinction between prototype and production is probably of fundamental importance. (I think that Dave Clark really meant "running service" when he said "running code".) d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
On Thu, Aug 02, 2007 at 11:55:12AM -0400, Keith Moore wrote: > DHCP, in particular, strikes me as a nightmare - a hodgepodge of > unrelated attributes, many of which have no business being dictated to > hosts by the network. gluing DHCP to DNS creates another set of > problems, also based on dubious assumptions about the relationship > between a host's identity and the attachment point of a host to the > network. and this all strikes me as a consequence of developing network > configuration protocols "organically", i.e. without much forethought. We clearly have a very different perception of reality. > more broadly, I wish there were a better feedback path from operators to > IETF to take advantage of the breadth of operational experience. it's > not as if the incidents occurring in IETF meeting networks are typical; > it's just that we experience them directly and as a group rather than > indirectly or as individuals. Contrarily, we should specifically seek not to make decisions about events that have affected us personally, because we have biases in our position towards recommended changes. That is, it further closes the gap on making IETF protocols designed explicitly for operation at IETF meetings, and nowhere else. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. Hankins"If you don't do it right the first time, Software Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgpYD8kMXuEV6.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: on the value of "running code" (was Re: Do you want to have more meetings outside US ?)
Lixia Zhang wrote: .. I think we've seen several examples of where the IETF has spent significant amount of energy, ranging from heated discussions to specification work, on solutions that simply won't fly. It would be useful if that energy waste could be reduced. Having 'running code' as a barrier for serious consideration within the IETF may be one approach. I agree that running code should be given extra weight, but I am not sure that running code should be a requirement for something which is not well understood yet (some Lemonade WG documents come to mind). forgive me for jumping into the middle of a discussion (and I did not know which of the lemonade doc's the above referred to), but my past experience seems suggesting that an attempt to implement a "not well understood" idea is a good way towards a better understanding of how to make the idea work, or what can be potential issues. Yes, but this is only useful once one understands what is actually needed in a spec to begin with ;-). I found running code most useful when the spec is nearly ready for publication. IMHO, "running code" gets more credit than is warranted. While it is certainly useful as both proof of concept and proof of implementability, mere existence of running code says nothing about the quality of the design, its security, scalability, breadth of applicability, and so forth. "running code" was perhaps sufficient in ARPAnet days when there were only a few hundred hosts and a few thousand users of the network. It's not sufficient for global mission critical infrastructure. it seems to me the above argues that running code is necessary, but not sufficient as evidence of a sound design. Agreed. Running code is useful to identify things that are difficult to implement or unclear. (well, that is the interpretation; I have not seen anywhere a claim that running code is sufficient, but rather simply to filter out the weed) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
On Wed, Aug 01, 2007 at 03:01:40PM -0400, John C Klensin wrote: > I think you misunderstand my comment, or at least its intent. I absolutely did, but I think reasonably so. This version is no longer crazy, even noble. But I'm not sold on it. > Or do you still think we disagree or that my comments are > fallacious? We're half in agreement. Where a problem manifests, and an operator intended the configuration as being reasonable and correct, then the reasons why the setup is neither, or what failed, should be documented. I would expect we should hear very loud noises in any event where this is the case. Where a problem manifests, and it was an accidental mishap of misconfiguration? It's a waste of time to pursue and document these with the kind of rigorous investigation you suggest. I suspect this is just a position we will disagree on, but I will explain myself a little; First, people who make mistakes on accident are not going to read a document telling them not to do that beforehand. If they did read the document beforehand, well we're talking about _mistakes_ here... they're going to make mistakes anyway. Nor will they look to an RFC after it is done. They'll seek FAQs, mailing lists, and their products' support chains. They'll seek an expert on the subject because there are simply too many references to read in a timely fashion to find the one that tells you what mistake you made. So it is certain that documenting this will make no real difference to anyone, and I think the "IETF Mindshare" gains are dubious at best. Second, there are just so many different ways to misconfigure your network, we would be working at this until the heat death of the universe. Of course we'd want this to be a general investigation into accidental configurations, and not a DHCP Witch-Hunt. For IETF 69 alone, we'd have to look into why the DNS servers were reliably reachable but not reliably answering until Tuesday. To continue on beyond merely the mishaps of IETF 69, we'd have to provide such advice as: "Do not accidentally create ethernet duplex mismatches." "Do not accidentally load the full Internet BGP table into a 2501. Use Filters." "Do not accidentally urinate on your router while it is running. In fact, avoid accidental urination altogether. Messy." (True story, a housecat in Maui did this to one of our Portmasters) "Do not make typos, especially not ones which happen to pass parsing tests, such as but not limited to reversing digits on subnet masks." Or my personal favorite: "Do not accidentally run outdated software with known bugs, possibly including well-used security vulnerabilities. Upgrade!" This list could go on! Basically, I think the best thing to do is to just expect our network's operators to raise the flag themselves if they think it is useful. That is, that something might come of it. This ietf@ business of inserting ourselves into the situation because of some possibility of a difficult problem that we hope we might be useful in addressing is another waste of time. -- Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. -- David W. Hankins"If you don't do it right the first time, Software Engineeryou'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins pgpkb6Lj8m9Fa.pgp Description: PGP signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: on the value of "running code" (was Re: Do you want to have more meetings outside US ?)
Lixia Zhang wrote: .. I think we've seen several examples of where the IETF has spent significant amount of energy, ranging from heated discussions to specification work, on solutions that simply won't fly. It would be useful if that energy waste could be reduced. Having 'running code' as a barrier for serious consideration within the IETF may be one approach. I agree that running code should be given extra weight, but I am not sure that running code should be a requirement for something which is not well understood yet (some Lemonade WG documents come to mind). forgive me for jumping into the middle of a discussion (and I did not know which of the lemonade doc's the above referred to), but my past experience seems suggesting that an attempt to implement a "not well understood" idea is a good way towards a better understanding of how to make the idea work, or what can be potential issues. yes! I tried to resist the 47th rehash of this thread, but... too late... Within a commercial environment, the organization has to be fairly convinced that their better mousetrap is going to work, in order to fund it, productize it, document it, sell it, and support it. This process will always find more bugs in the mousetrap than simply documenting it and skipping all the other steps. If a vendor bothers to do all this, and multiple IETFers can say in a BoF that they have used the mousetrap and it really does work, that is worth a whole lot more than "I read the draft and it looks pretty good". There is a certain amount of healthy risk that the IESG can take when chartering new standards-track work. Prior implementations should not be a gating factor, but it makes their decision much easier when there is objective evidence the mousetrap actually works and it is already being used by the industry. But implementation and deployment are not enough alone. There also needs to be some pre-existing consensus that a standard version could be written and approved by the IETF, and people are willing to work on it. The slogan says "rough consensus and running code". It doesn't say "rough consensus, then running code". Without running code, there is no deployment. Without deployment, there is no point to this exercise. Andy IMHO, "running code" gets more credit than is warranted. While it is certainly useful as both proof of concept and proof of implementability, mere existence of running code says nothing about the quality of the design, its security, scalability, breadth of applicability, and so forth. "running code" was perhaps sufficient in ARPAnet days when there were only a few hundred hosts and a few thousand users of the network. It's not sufficient for global mission critical infrastructure. it seems to me the above argues that running code is necessary, but not sufficient as evidence of a sound design. (well, that is the interpretation; I have not seen anywhere a claim that running code is sufficient, but rather simply to filter out the weed) Lixia ___ 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: on the value of "running code" (was Re: Do you want to have more meetings outside US ?)
.. I think we've seen several examples of where the IETF has spent significant amount of energy, ranging from heated discussions to specification work, on solutions that simply won't fly. It would be useful if that energy waste could be reduced. Having 'running code' as a barrier for serious consideration within the IETF may be one approach. I agree that running code should be given extra weight, but I am not sure that running code should be a requirement for something which is not well understood yet (some Lemonade WG documents come to mind). forgive me for jumping into the middle of a discussion (and I did not know which of the lemonade doc's the above referred to), but my past experience seems suggesting that an attempt to implement a "not well understood" idea is a good way towards a better understanding of how to make the idea work, or what can be potential issues. IMHO, "running code" gets more credit than is warranted. While it is certainly useful as both proof of concept and proof of implementability, mere existence of running code says nothing about the quality of the design, its security, scalability, breadth of applicability, and so forth. "running code" was perhaps sufficient in ARPAnet days when there were only a few hundred hosts and a few thousand users of the network. It's not sufficient for global mission critical infrastructure. it seems to me the above argues that running code is necessary, but not sufficient as evidence of a sound design. (well, that is the interpretation; I have not seen anywhere a claim that running code is sufficient, but rather simply to filter out the weed) Lixia ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
David W. Hankins wrote: > I certainly would say that, given what we can observe as users, the > possible explanations for the DNS and DHCP service outages reside in > a _very_ limited set; hardware, software, configuration, or some > combination. > > None of those are "IETF business" in the sense of things which we can > observe or change through "Reviewing our protocols and > specifications" as John Klensin appears to have suggested. > doesn't follow. in particular, I don't think we in IETF pay nearly enough attention to architecture, nor to making our protocols easy to configure. DHCP, in particular, strikes me as a nightmare - a hodgepodge of unrelated attributes, many of which have no business being dictated to hosts by the network. gluing DHCP to DNS creates another set of problems, also based on dubious assumptions about the relationship between a host's identity and the attachment point of a host to the network. and this all strikes me as a consequence of developing network configuration protocols "organically", i.e. without much forethought. now it might be that this specific incident has little to do with the lack of a configuration architecture in IP. but I do think that IETF would do well to analyze such incidents when they do occur and try to learn from them. such lessons might impact future protocol designs at both an architectural and a detailed level. more broadly, I wish there were a better feedback path from operators to IETF to take advantage of the breadth of operational experience. it's not as if the incidents occurring in IETF meeting networks are typical; it's just that we experience them directly and as a group rather than indirectly or as individuals. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
On 2007-08-01 21:01, John C Klensin wrote: --On Wednesday, 01 August, 2007 09:03 -0700 "David W. Hankins" <[EMAIL PROTECTED]> wrote: ... This is also just another version of the "eat our own dogfood" story: if we don't find the dogfood palatable --whether because of its basic specification or its formulation or packaging in practice-- then we need to do something about it. Clever, but wrong: networks much larger than 1,200 laptops use DHCPv4 on a daily basis all over the Internet without similar symptoms. I know that. I've also got some hypotheses as to why we have problems and they don't, but my hypotheses aren't backed by solid data and analysis and hence aren't worth much. So do you have an explanation for the repeated IETF problems? Generically, I think there must be two places to look for the explanations (plural, certainly): 1. The fact that the network is expected to be shaken down within hours instead of progressively over some large number of days. It goes from small scale test to full load in about 24 hours. 2. The fact that the client systems are highly heterogeneous and some of them will probably be running beta code. That combination of circumstances is going to stretch any dogfood. And, if not, are you willing to join me in suggesting it is about time the IETF gets to the bottom of these problems, gets the finger pointed in an appropriate direction, and gets the problem or problems fixed? Personally I have no doubt that it's strongly in Verilan's enlightened self-interest to get to the bottom of the problems. It would be interesting to know if the observed failure modes are caused by bad implementation, by lack of robustness in the various protocol designs, or both. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
-- Original message -- From: John C Klensin <[EMAIL PROTECTED]> > > > --On Tuesday, 31 July, 2007 01:23 -0400 Jeffrey Altman > <[EMAIL PROTECTED]> wrote: > > > The notion that NomCom eligibility should be determined by > > those who attend meetings just doesn't make a lot of sense for > > an organization that prides itself on only making consensus > > decisions on mailing lists. ... > I wouldn't go so far as "doesn't make a lot of sense", although > I agree that it is problematic. The difficulty has been, in > part, that no one has proposed a better system and, in part, > because of an assumption that the meeting-attendees are much > more likely to be in touch with personality, skills, and > behavior patterns than those who particular purely by mailing > list. I was one of the folks who invented the noncom eligibility scheme way back when. the nomcom's job is evaluating people and their suitability for a particular job. our view at the time, and my view still, was that the best way to accomplish that task is to actually see that person in action -- to see how they conduct themselves in meetings, how they deal with "issues", how they think on their feet, and so on. one might argue that looking at the email record would suffice -- but on the internet, no one knows if you're a dog or not... this does skew the candidate pools for both the nomcom and iab/iesg positions to people who attend meetings. we knew that then. we felt that it was a relatively minor downside. and besides, the meetings _are_ an important part of the ietf/etc... > Of course, the latter assumption becomes more dubious as > the community gets larger and the Nomcom members know > proportionately fewer people and need to rely more on what they > can learn from interviews and questionnaires than on their > personal knowledge and experience. while true, it is a significant problem if one wishes the nomcom to find The One Best person for a job. if one is willing to accept a person who is "good enough", then evaluating a smaller percentage of a larger pool is probably ok. the scheme is not perfect -- but perfection was not the goal. workability and simplicity were. frank kastenholz ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
Hi Peter, --On July 30, 2007 2:11:38 PM -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote: Further, in-person meetings are so second-millennium. How about greater use of text chat, voice chat, and video chat for interim meetings? Are three in-person meetings a year really necessary if we make use of collaborative technologies that have become common in the last 15 years? All that will do is shift the discussion from "where shall we hold the meeting" to "what time/timezone shall we have for our conf call". Given that we have people participating from across the globe, trying to arrange a time that is acceptable for all participants will be just as hard as trying to find a meeting venue acceptable to all. Unfortunately we don't have scheduling tools that will help resolve issues like that (or at least make it easier than a multiple party email exchange/negotiation) - but some of us are working on that! -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Beggars _can_ be choosers?
We've got an IAD, whose responsibility it is to check that contractors (YES, there were contractors, not just volunteers, involved in the network setup) do what they contracted to do. I'm sure he knows enough to ask for help in evaluating the answer, if he doesn't understand it. Asking people to explain what's going on does NOT necessarily mean that it's useful to have the question, or the answer, broadcast across the whole IETF list. It's Ray's responsibility to figure out how to handle the "quality of network" issue. I'm not going to second-guess him in public. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Charging I-Ds
On Wed, Aug 01, 2007 at 11:05:35AM -0700, Bob Braden <[EMAIL PROTECTED]> wrote a message of 31 lines which said: > [Of course, when the IAOC outsources the RFC Editor to India in > 2009, Good idea. May be the indians will process the errata in time? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Do you want to have more meetings outside US ?
On Sun, Jul 29, 2007 at 05:51:21PM +0200, Arnt Gulbrandsen <[EMAIL PROTECTED]> wrote a message of 21 lines which said: > Five days in Minneapolis I thought we did not want to have meetings in dangerous places like Paris or Rio? http://www.cnn.com/2007/US/08/01/bridge.witness.ap/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
