Gen-art review of draft-ietf-ipv6-deprecate-rh0-01
I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-ipv6-deprecate-rh0-01.txt Reviewer: Elwyn Davies Review Date: 21/9/07 IETF LC End Date: 20/9/07 IESG Telechat date: (if known) - Summary: This document is almost ready for the IESG. I have a couple of essentially editorial comments below. Comments: s3: "IPv6 nodes **MUST NOT process** RH0 in packets whose destination address in the IPv6 header is an address assigned to them. Such packets...": The rest of the section then goes on to describe just how the node processes the header! I think it should say something like: "An IPv6 node that receives a packet with a destination address assigned to it and containing an RH0 extension header MUST NOT execute the algorithm specified in the latter part of Section 4.4 of [RFC2460] for RH0. Instead such packets..." s4.2, para 1: The abbreviation RH is not defined (only RH0) so s/type-2 RH/type 2 Routing Header/ Discussion: This document accurately reflects the consensus that was reached in the community but there was considerable discussion about the appropriate course of action having discovered the issue. I think that a short appendix noting the alternative ways forward and the reasons for not taking them would have been useful to avoid revisiting the discussion in future. _ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On 20-sep-2007, at 21:10, Stephen Sprunk wrote: First of all, litigation isn't the only way to get something done, and second, do don't know that until you try. If you try to revoke someone's /8 or /16, you can bet that they're going to sue you. So? The RIRs and ICANN have deep pockets. But there are other approaches than simply revoking the address space. For instance, setting up a policy that governs who gets to keep legacy space that takes into consideration various types of use and cost of renumbering makes sense. I'm sure some legacy space is used in a way that's fairly reasonable, while other space isn't used at all. Obviously the elephant in the room is the US government that has about 5% of all address space, which seems excessive even for legacy holders. And, for the record, there are over 50,000 of them, not less than 50. Clarification: 31,386 in ARIN's region. I haven't seen stats for the other RIRs. 5 organizations holding nearly 0.5% of the IPv4 space each? I'm impressed! With that kind of address compression technology we don't need IPv6 after all. I'm sure you're aware that different size assignments were made to different organizations. I was specifically talking about the /8s, where you get a decent bang for your reclaiming effort buck. But even that isn't enough anymore to bother at this point... Even if true, that point is past. Based on current projections, it is unlikely we'd be able to recover _any_ /8s before exhaustion hits due to the protracted litigation that would ensue, and even if we did manage to get some of them back (which isn't guaranteed, and would cost millions of dollars in any case), What would that be, $0.25 per address? Big deal. IPv6 still won't be deployed and usable in any meaningful way unless we make more progress in the next two years than we have in the last ten. Progress in various aspects of IPv6 has been slow because it didn't need to be faster. I see no solvable issues with IPv6 deployment that can't be solved in those 2 years. (No, we still won't have routing that will take us to the next century by then, but I suggest we don't wait for that.) Same thing for repurposing 240/4, by the way. Decade problem. Come back and discuss that when Windows recognizes that block as normal unicast addresses by default. If we had done this two years ago it could have been in Vista and in an XP update, so the space would have been usable by 2010 or so when the older Windows versions and other implementations that don't accept these addresses would have had the time to be updated manually or replaced. Maybe the RIRs have contracts with all new PI holders, but that doesn't automatically give ARIN the authority to reclaim address space after a policy change. Again, I don't know about all RIRs, but that is _explicitly called out_ in ARIN's Registration Services Agreement RIRs would still have to show that it's a reasonable thing to do. I'm still not a lawyer, but I could easily come up with several arguments why I should be able to keep my addresses despite any contracts. and AFAIK has been since day one. I have never heard of a case where an otherwise legitimate organization (i.e., not a front for a spam outfit or some such) used address space in a way that wasn't abusive or criminal, but didn't comply with RIR policies and got those revoked. As a non-lawyer, I would judge the chances in court for reclaiming IPv4 /8s higher than those for reclaiming IPv6 PI space: in the first case, it's the benefit the continued operation of the IPv4 internet, in the latter case, it's going to look highly arbitrary. I'd suggest you review the comments by ARIN's counsel at the last meeting WRT revoking legacy assignments. It's more complicated than it appears at first glance, particularly to someone not used to our legal system. Isn't everything? The opinions of one lawyer aren't worth much. As a profession, they lose 50% of all their cases, so obviously they must be wrong 50% of the time. (Not sure if engineers do better, though.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On 20-sep-2007, at 21:19, Stephen Sprunk wrote: Sometimes ignoring a problem really does make it go away. Install a workaround, on the other hand, and the brokenness remains non-obvious so it persists. If often persists whether it remains non-obvious or not. I can't count how many hotels I've visited where I have to disable v6 on my laptop for v4 DNS to work Yes, hotels are the worst. In Chicago two months ago they used a NAT timeout in my hotel that was so short that my SSH, IMAP and IM sessions timed out every few minutes. because their boxes break horribly when confronted with an lookup. This has been going on for _years_ and the operators and vendors obviously don't care even though the problem is blatantly obvious. Obviously this should be fixed. But: you may ask yourself: why is your system doing lookups when you obviously don't have IPv6 connectivity? I'm not advocating going around and breaking implementations that don't fully conform with specs on purpose, but if doing the right thing means that out-of-spec implementations see some problems, I can usually live with that. Whether I can live with that in a particular case depends on what percentage of the userbase will see "some problems" if that brokenness is exposed. Ah yes, the "if enough people do something wrong it becomes right" doctrine. So here in Holland we have "alcohol free" beer that contains 0.5% alcohol, and megabytes are now 100 bytes. For instace, we accomodate multi-faced DNS because most "major" web sites would become inaccessible if it weren't. ??? How come? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Representation of end-users at the IETF (Was: mini-cores (was Re: ULA-C)
Paul Hoffman wrote: > Why the IETF? Why not ISOC, an organization that has expertise and > experience is asking such questions? ISOC already has local chapters > throughout the world, ISOC has a friendly membership policy, and ISOC > has good relations with the IETF for discussing proposed improvements to > the Internet. I founded an ISOC chapter some years ago among others to see how users could provide input to the standards development process. However, there is no mechanism to consult, collect and present such information in an organized way. You could say that, as an ISOC trustee, I would need to submit a proposal to the board, and this is exactly what I intend to do. Keep in mind though that those volunteers in chapters may expect that some consideration and feedback is being given to their (sometimes non technical) comments. If they are by default considered irrelevant, hobbyist rubbish, this may kill the process in the egg. Part of the goal of this discussion, for me, is to see how the IETF community welcomes such a proposal. If I get the impression that it is not supported, I won't spend more time on it. Patrick . ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Spam solution?
Welcome, I'm a system administrator of a secondary school, and ive installed a spam filter a couple days ago, to prevent spam. The problem is the various spam images there is used graphical attachments, a lot of different words to advertise their products. Now I have strong filter, so I afraid to drop the mail was written in english. I think to need an new e-mail rules, to stop this madness. I call it application card. When somebody want to make a contact with somebody, should send a "request card". This would be an empty mail without subject, with a special flag. So the spammer cannot advertise. The user's mailer would have a new folder, e.g. "request cards folder" (with a lot of sub-folder for every day) so the user can decide with a copule of clicks to accept somebody connectionship request. Naturally, the user can ban this connectionship licence later, if it is wanted. Users would give license, an entire domain if they want. If somebody send a mail without license, would receive an auto-reply: need to get a licence. With the chechking this new "license flag" can be seen the suspicious sources, where arrives too much ask for request. Sincerely Cserny Zsolt ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spam solution?
More opportunities of the request card: If it would br given an quota for each e-mail domains to send application request card, that is more possibility to stop spanning, because, the spammers want to get connection thosands of users. But if there is already a relationship between 2 address, after can send unlimited e-mails. The request card system can be managed by an administrator also, for each users. There would be an e-mail address, the "entry point" managed the sysadmin, to this address came the requests for licence to sending emils the managed domains. So this entry point would works as a "e-mail firewall". ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spam solution?
[EMAIL PROTECTED] wrote: I think to need an new e-mail rules, to stop this madness. I call it application card. Nice try, and I can say for sure that the basis of your idea is good enough to make products that people were willing to pay for... a few years ago. Unfortunately it makes one or two classic mistakes, which have been figured out in the meantime. If I understand rightly, it depends on spammers to go along with it, sending an application instead of a plain email. If they were that civil, the entire spam problem would have dried right up shortly after people started objecting to it. If you mean that the user would set it up in such a way that this would be automagically enforced for all new contacts, that relieves the dependence on the civility of the obviously uncivil. Even then, though, the mechanism itself has been thought of before. It's generally called challenge-response. It may be acceptable for people who receive a tiny volume of unsolicited but desired email, or solicited email from new contacts. However, for the rest of us, it doesn't work very well. It imposes a burden, small but tiresome, on our new correspondents, that many are not willing to bear. In fact, much of the email we want to get, is sent by automated mechanisms that simply *cannot* respond to it. (Some might think that the answer is to establish standards for the format of the challenges and responses, so that these automated systems can respond. I think it's a pretty safe bet that the spammers would then start using such systems. Back to Square One, just with a lot more money down yet another rathole, and more pain for the innocent. A while back I gave some thought to designing standards for signing up for automated emails, in such a way that the source would be automagically added to your "whitelist". That never really got anywhere either, but I suspect that it also would have been abusable by spammers.) Lastly, unless the request cards folder, with its many subfolders, is going to be managed automagically by the email program, this sounds rather unwieldy. The spam problem is deceptively simple-looking from the point of view of the typical user, or even administrator. I suggest you check out the Internet *Research* Task Force's working group on spam, called the Anti-Spam Research Group or ASRG. Their home page is at http://asrg.sp.am/. A lot of it consists (or at least when I hung out there, consisted) of going round and round in circles, actually accomplishing very little, but you can learn a lot from the discussions, about how complex the problem really is, what has been tried, and why certain approaches are absolutely doomed. -Dave (no, not that one, no, not that other one, the other other one) -- Dave Aronson "Specialization is for insects." -Heinlein Work: http://www.davearonson.com/ Play: http://www.davearonson.net/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Spam solution?
On Fri, Sep 21, 2007 at 12:44:48PM +0200, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote a message of 59 lines which said: >I think to need an new e-mail rules, to stop this madness. I >call it application card. Please, please, please, a *lot* of time and effort have been devoted to the spam issue. Do not start from the beginning, spend some time first to learn what others did. Check your "solution" againt FUSSP (http://www.rhyolite.com/anti-spam/you-might-be.html) first. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ideas getting shot down
Thus spake "Keith Moore" <[EMAIL PROTECTED]> At the same time, IETF needs to understand that optimizing for deployability first and scalability second often succeeds whereas the reverse often fails. We need to understand how to design protocols that can be deployed quickly and yet be upgraded gracefully as the real requirements for long-term widespread use of the protocols become apparent. This is the true failing of the IPng effort: all the attention was focused on the end result, with virtually no effort towards a viable transition model. A contributing factor was that the IETF designed IPng in a vacuum and tossed it over the wall to operators, and completely ignored (and is still ignoring) feedback on why people aren't deploying it. A large part of this hubris comes from the success of IPv4 itself. There were dozens of different L3 protocols in use in the 80s and early 90s, so operators had little problem adding yet another one to their networks -- and IPv4 was so much better than the others that the remainder faded away rather quickly in the mid 90s. It seems to have been assumed that operators would have no problem going back to the dual-stack model to get IPv6 and would drop IPv4 relatively quickly. However, since v6 isn't much better than v4 (arguably worse, if one considers the number of hosts reachable, equipment replacement, staff retraining, etc.), it just hasn't happened. Add to that a transition model that _requires_ that every host be dual-stacked before the first v6-only node appears and you've got a horrible chicken-and-egg problem where nobody has any incentive to create a critical mass of dual-stacked hosts. Also add in how long it took MS to ship an OS with v6 on by default; that should have happened by 1998 or 2000 -- not 2007. NAT-PT was a reasonable solution to this (with a few tweaks), since it could make hosts _appear_ to be dual-stacked with little effort, but it offended the purists and was killed despite there being nothing to replace it. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ideas getting shot down
Stephen Sprunk wrote: > Thus spake "Keith Moore" <[EMAIL PROTECTED]> >> At the same time, IETF needs to understand that optimizing for >> deployability first and scalability second often succeeds whereas the >> reverse often fails. We need to understand how to design protocols >> that can be deployed quickly and yet be upgraded gracefully as the >> real requirements for long-term widespread use of the protocols >> become apparent. > > This is the true failing of the IPng effort: all the attention was > focused on the end result, with virtually no effort towards a viable > transition model. That's actually not true; at least one proposal that got some traction was very focused on a viable transition model. But more people were concerned about the end result. And I do think this is a kind of second-system effect. > A contributing factor was that the IETF designed IPng in a vacuum and > tossed it over the wall to operators, and completely ignored (and is > still ignoring) feedback on why people aren't deploying it. To me it looks like operational issues drove all of the design changes between v4 and v6. But the operational issues were ISP operational issues, not operational issues in enterprise networks. But it's almost a given that there would be a long feedback path. The users will be the last to understand and react to any major architectural change. It's hard for them to really know what they're getting and how to deal with it until it actually ships in products that they're using. Also, users are very diverse, and the way the network is used is constantly changing, so it's hard to anticipate what users will need, say, 10 years hence when the stuff finally gets deployed. > Also add in how long it took MS to ship an OS with v6 on by default; > that should have happened by 1998 or 2000 -- not 2007. Well, it took them until 1995 to ship IPv4, and even then it wasn't "on by default". :) > NAT-PT was a reasonable solution to this (with a few tweaks), since it > could make hosts _appear_ to be dual-stacked with little effort, but > it offended the purists and was killed despite there being nothing to > replace it. No, NAT-PT was not a reasonable solution, because it would have crippled the IPv6 network even moreso than the NATted IPv4 network, in addition to trashing DNS, and without providing any incentive to move to a native (non-NATted) IPv6 network. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: ideas getting shot down
> Add to that a transition model that > _requires_ that every host be dual-stacked before the first > v6-only node appears and you've got a horrible > chicken-and-egg problem where nobody has any incentive to > create a critical mass of dual-stacked hosts. If that was true, you'd be right, but it's not, therefore you are wrong. >From an operator viewpoint, IPv6 can be deployed without dual-stack either by using 6PE on an MPLS core, or by building an IPv6 overlay core using tunnels. Neither requires dual-stack everywhere, in fact both models of deployment are desirable specifically because they focus the change on just one part of the network. > NAT-PT was a reasonable solution to this (with a few tweaks), > since it could make hosts _appear_ to be dual-stacked with > little effort, but it offended the purists and was killed > despite there being nothing to replace it. What's this about NAT-PT being killed? I still see vendor literature which mentions NAT-PT support. If it works, and it is implemented, then people will use it. Same thing goes for Application Layer Gateways, i.e. proxies. I don't think any network operator is in the business of being an IETF purist. It is desirable that hardware and software adheres to standards but it is more important for them to *WORK*!!! And if there is a standards vacuum, that will not stop deployment. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Representation of end-users at the IETF (Was: mini-cores (was Re: ULA-C)
We are all end-users, the question is whether the work here should be more responsive to the needs of typical end users. We have interminable discussions premised on the bizare assumption that the typical end user cares more about whether he has a /48 or /56 than whether his or her network works reliably, without fuss, supports the applications they want to use and does not make them artificially dependent on a particular service provider. Equally you can be sure that in any discussion of a proposed change to the Internet that there will be someone who will come up with the equivalent of 'but if we phase out use of UUCP that will cause systems which people rely on in remote parts of Africa to fail', and you can be sure that the person raising the objection 1) has never been to Africa, 2) has zero personal contact with anyone in Africa who has the issue he claims to be critical, 3) is entirely ignorant of the constraints under which Internet management in Africa operates, 4) has some 30 year old UUCP installation that they want to keep running for personal reasons. We used to have the same issue with accessibility. Some people would bring up accessibility in a similarly insincere fashion. By this I mean using accessibility as a debating maneuver without any real interest in meeting needs of disabled persons. That is rather harder today, first there are quite a few people in the IETF who have direct experience in those areas, either as a user or developer of accessibility technologies, second there is a whole accessibility effort in W3C that focuses on the issues directly. So when folk object that using PKIX logotypes in certificates rasies accessibility issues with blind and partially sighted people I have a lot of resources I can draw on. I talk to the people concerned, take their input into account and come up with a (slightly) revised proposal. I don't think it is actually very difficult to become an advocate for the ordinary user. Just decide to become 100% intolerant of network administrivia. When friends or relatives ask for help setting up their systems ask why the assistance is needed and how the network could be changed to make that help unnecessary. Sit in on some usability tests for real products. It is quite interesting watching someone who claims tho be proficient in the use of certain network infrastructures actually using them to achieve what should be routine tasks. The User Interface itself may be out of scope for a protocol but the need for user interaction is not. In particular a protocol must provide the information necessary for the UI to function. A very large number of UI issues are really caused by poor architecture, lack of though given to error conditions is a major cause. In PKIX the protocols make the bizare assumption that every Internet user wants to become a trust engineer. This is better than the original assumption that PEM was based on but still too far away from the idea that everyone wants to have the choice of who they delegate their trust management tasks to. > -Original Message- > From: Jeroen Massar [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 19, 2007 6:30 PM > To: Stephane Bortzmeyer > Cc: ietf@ietf.org > Subject: Re: Representation of end-users at the IETF (Was: > mini-cores (was Re: ULA-C) > > Stephane Bortzmeyer wrote: > > On Wed, Sep 19, 2007 at 12:50:44AM +, Paul Vixie > <[EMAIL PROTECTED]> > > wrote a message of 32 lines which said: > > > >> in the IETF, the naysayers pretty much kick the consenting adults' > >> asses every day and twice on sunday. and that's the real problem > >> here, i finally think. > > > > Time to have a formal representation of end-users at the IETF? > > What is defined as an 'end-user'? > > You, me, the rest of the people, are all end-users IMHO. > > That we might have quite a bit more knowledge on how things > work and that we might have some connections to people so > that we can arrange things, is nothing of an advantage over > people who are not technically inclined (or how do you put > that nicely ;) > > The point is that those people don't know better and as such > they also don't know what is possible and what they are missing. > > Eg, if you tell somebody "oh but I have a /27 IPv4 and a /48 > IPv6 at home and I can access all my computers from the > Internet wherever I am", they will be going "and? why would I > need that". The typical lay-man end-user really couldn't care > less, as long as their stuff works. > > The only people really noticing problems with this are > hobbyists and most likely the gaming crowd trying to setup > their own gameserver and finding out that they are stuck > behind this thing called "NAT". > > P2P people, thus quite a large group of people using the > Internet today, have their tools to nice NAT tricks, thus > these won't notice it. > > And for the rest of the population the Internet consists of
Re: [Geopriv] Response to appeal dated 22-June-2007
I believe this response (I hope inadvertently) appears to remove a valuable principle by which the IESG acted on appeals. I urge the IESG to reconsider the formulation of its response to the appeal to clarify the issues raised below. At 2:01 PM -0400 9/20/07, The IESG wrote: >IESG Response to the Appeal Against the Removal of the Co-chairs of the >GEOPRIV Working Group > > >Introduction > > This is the IESG response to the appeal by Randall Gellens, Allison > Mankin, and Andy Newton posted at: > > http://www.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf > > Cullen Jennings recused from all discussion of this appeal. > > The appeal raises three major points for the IESG to address: > > 1. The removal of the WG Chairs violates IETF process; > > 2. The actions taken interfered with the consensus process; and > > 3. There is a conflict of interest. > > The appeal also proposes a remedy. This response includes some > comments about the proposed remedy. > >1. The removal of the WG Chairs violates IETF process > > RFC 2418 says: > > Working groups require considerable care and feeding. In addition >to > general participation, successful working groups benefit from the > efforts of participants filling specific functional roles. The Area > > Director must agree to the specific people performing the WG Chair, > > and Working Group Consultant roles, and they serve at the >discretion > of the Area Director. > > Since all WG chairs "serve at the discretion of the Area Director," > they can be replaced at any time. The previous GEOPRIV WG co-chairs > were told about their removal in private before the public > announcement. This action was not required, but it is the most > polite way to handle the situation. Perhaps the public announcement > could have provided some rationale, but the authority to remove a WG > chair is clear. In this response, the IESG appears to have read the appeal to state that the removal of the chairs was not within the authority of the Area Director. The appeal statement: http://www3.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf does not support this reading. It does not say that Area Directors do not have the right to remove chairs, it says that the manner and timing by which this was done interfered with the consensus process inappropriately. The remainder of the IESG statement below appears to attempt to address the interference issue. But in choosing to highlight that all "WG chairs serve at the discretion of the Area Director", the IESG appears to be saying that the personnel decisions of an Area Director or the IESG are not subject to appeal. During the time I served on the IESG, it was a general guideline that *any decision* of an Area Director or the IESG was subject to appeal to the IESG. While this is a broad reading of RFC 2026, Section 6.5, I think it is an important point and a principle worth retaining. The appeals process in the IETF is not simply a mechanism for establishing who has what rights; it is a mechanism for conflict resolution. By making all decisions subject to it, we ensure that conflicts which arise are dealt with as early as possible and with as little process as possible. If members of the community believe that a personnel decision was made in a way the interfered with the proper operation of the IETF, I believe asking the IESG to attempt to resolve the conflict is an appropriate thing to do. This appeal response, which re-asserts the authority of the AD to make the original decision, does not seem to support this use of the IETF's normal conflict resolution mechanism. Further, this appeal response appears to say that the only conflict resolution mechanism open to those who disagree with a personnel decision is to invoke one of the removal mechanisms for those who made it. I hope that the IESG will re-structure its response to this appeal to re-affirm that the conflict resolution mechanisms of the IETF are available for this purpose. I also encourage the IESG (and, frankly, the IETF community as a whole) to try to see the appeals process as a way of resolving conflict, rather than a quasi-legal process for determining whether a remedy will be granted. I understand how previous appeals have pushed everyone in that direction, but it is something we must continue to resist. I have worked with Allison, Andy, and Randy for many years, as well as Cullen and Jon. They are all experienced IETF folks who have toiled for years to make things work; forcing them into even more adversarial positions when conflicts do need resolution is a mistake, at least I see it. My thanks for your attention, regards, Ted >2. The actions taken interfered with the consensus process > > The appeal claims that a sequence of events, including the > replacem
Vendor viewpoint on ULA filtered-by-default
Paul Vixie has asked me to more widely state a comment made last May on the v6ops mailer. Please understand that this is not a formal statement of Cisco's (e.g., this is not a press release signed off by the Cisco Legal, corporate PR, product line management, or marketing departments), it is my personal opinion of how Cisco will apply its design guidelines and viewpoints to the ULA concept. Barring the influx of large numbers of dollars from a customer coupled with a change request, it represents what I consider to be Cisco's probable course of action. The context is RFC 4193's statement that The default behavior of exterior routing protocol sessions between administrative routing regions must be to ignore receipt of and not advertise prefixes in the FC00::/7 block. A network operator may specifically configure prefixes longer than FC00::/7 for inter-site communication. Cisco thinks ULAs are wonderful things if our customers think they are wonderful things. In http://tools.ietf.org/html/draft-baker-v6ops- b2b-private-routing, I have identified a particular way we might consider using them across administrative boundaries. In other email, I have suggested that systems that we don't want the external world to access (labs, internal-only servers, etc) could similarly be addressed using ULAs that are not advertised across administrative boundaries. Doing this would likely simplify firewall rules. However, we are unlikely to change our configuration methodologies for BGP in a manner that changes existing customer configurations (such as by turning off a portion of the address space that our customer has configured to be available, or by rearranging his route maps without his consent), and we are unlikely to create magic configurations such as "turning on BGP for IPv6 for the first time suddenly creates a three stage route map, partially filled in". We try to operate on what we call the "Principle of Least Surprise". Our customers tell us that such things are "surprising". One could imagine a "simple-bgp6-configuration" macro that would accept a few prefixes and a few neighbor names or addresses as arguments and build a simple initial BGP configuration that the administrator could then flesh out to his heart's content, but even the application of that would be the operator's choice. What we *are* very likely to do is post configuration guidance for BGP for IPv6 on our web site, with a note regarding the importance of filtering out ULAs as a class and indicating how to advertise and accept more specific ULAs when appropriate. To see what that might contain, take a look at http://ops.ietf.org/lists/v6ops/v6ops.2007/ msg00391.html, which is in reply to http://ops.ietf.org/lists/v6ops/ v6ops.2007/msg00377.html. In short, "not advertising" is easy - don't include them in the list of things to be advertised, and they won't be advertised. Denying their acceptance when announced by the peer is part of a BGP configuration's acceptance policy, which is something network operators usually prefer to configure themselves. This is consistent with the way we handle RFC 1918 prefixes and other martian prefixes in IPv4 networks. There is an obvious inherent bug in that, which has been observed in the IPv4 Internet with respect to RFC 1918 and martian prefixes. Administrations that don't apply the policy to deny ULAs will accept them, which will have the effect of leaking them if the peer inadvertently advertises them. The problem is that we, as a vendor, can't really tell the difference between clueful operators and clueless ones (their money all looks the same), and as a result make no attempt to save the world from one while trying to satisfy the other. This is a matter we feel should be included in operator education, one of many things the clueful operator needs to know. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 20-sep-2007, at 21:10, Stephen Sprunk wrote: First of all, litigation isn't the only way to get something done, and second, do don't know that until you try. If you try to revoke someone's /8 or /16, you can bet that they're going to sue you. So? The RIRs and ICANN have deep pockets. SCO had "deep" pockets too. IBM, Novell, etc. had much, much deeper pockets. Do you really think ARIN or ICANN could take on titans such as GE, IBM, AT&T, Xerox, HP, Apple, Ford, Halliburton, Eli Lilly, Prudential, and Merck? Even _one_ of them? ARIN would be squashed like a bug. Not to mention the entire weight of the USG if ARIN tries to mess with _their_ 13 /8s. I'm confident that the RIRs' membership would oust any leaders that knowingly got them engaged in significant litigation of this sort. But there are other approaches than simply revoking the address space. For instance, setting up a policy that governs who gets to keep legacy space that takes into consideration various types of use and cost of renumbering makes sense. I'm sure some legacy space is used in a way that's fairly reasonable, while other space isn't used at all. I have proposed policy for ARIN to head in that direction. We'll see if it passes next month. Obviously the elephant in the room is the US government that has about 5% of all address space, which seems excessive even for legacy holders. We don't know what the US DoD is doing with their addresses since that's classified; besides, it was their network to begin with so they do have some special priviledges. The remainder of the USG's address space appears reasonable given the number of hosts/employees/etc. I'm sure you're aware that different size assignments were made to different organizations. I was specifically talking about the /8s, where you get a decent bang for your reclaiming effort buck. But even that isn't enough anymore to bother at this point... Those /8s are held by orgs with significant financial resources and are all at least partially still in use. There are thousands of /16s and tens of thousands of /24s that can be reclaimed with less effort, time, and cost than a single /8 could be, because those smaller blocks aren't in use anymore. There's also a fair amount of squatting on LIR-issued blocks that were justified at the time but aren't anymore. Even if true, that point is past. Based on current projections, it is unlikely we'd be able to recover _any_ /8s before exhaustion hits due to the protracted litigation that would ensue, and even if we did manage to get some of them back (which isn't guaranteed, and would cost millions of dollars in any case), What would that be, $0.25 per address? Big deal. ARIN gets a _maximum_ of $0.034 per address from the "Xtra Large" ISPs that are consuming 80% of ARIN's address space. In reality, they would get $0 per address because those ISPs have already topped out on the fees they pay; once you pass a /14, you pay _nothing_ for additional addresses. My pleas to correct the fee schedule's indirect encouragement of massive waste have apparently fallen on deaf ears. IPv6 still won't be deployed and usable in any meaningful way unless we make more progress in the next two years than we have in the last ten. Progress in various aspects of IPv6 has been slow because it didn't need to be faster. I see no solvable issues with IPv6 deployment that can't be solved in those 2 years. The single biggest thing we need now are consumer CPE boxes that understand v6 and have 6to4 on by default. The host issue will take care of itself over the next couple of years as non-Vista machines wear out and are replaced. We also need specialty boxes like load balancers, firewalls, NMS, etc. to gain v6 support, but that problem is a few orders of magnitude smaller in scope and could be solved within 2 years by operators beating on their respective sales droids _today_. (No, we still won't have routing that will take us to the next century by then, but I suggest we don't wait for that.) No offense to the ISPs, but fixing the DFZ is a relatively small problem _to deploy_ compared to upgrading a billion end-user sites. It's a much harder problem to come up with a solution for, though -- and the sort of problem the IRTF and IETF seem to be best at. Same thing for repurposing 240/4, by the way. Decade problem. Come back and discuss that when Windows recognizes that block as normal unicast addresses by default. If we had done this two years ago it could have been in Vista and in an XP update, so the space would have been usable by 2010 or so when the older Windows versions and other implementations that don't accept these addresses would have had the time to be updated manually or replaced. v6 _could_ have been in NT4, Win98, WinMe, Win2k, WinXP, or Win2k3. It wasn't; it was first implemented and on by d
Re: [Geopriv] Response to appeal dated 22-June-2007
Ted, speaking as an individual. I completely agree that personnel decisions of ADs should be able to be appealed. I actually considered proposing text modifications to make it clear that there might be circumstances where it would be appropriate for the IESG to resolve the conflict. I and I suspect others were working on the "good enough" principle and were trying to get a good enough response produced and not deal with all potentially different future situations. So, I do agree that at least from my standpoint this defect in the response was inadvertent. My preferred way forward would be for IESG members to individually either agree or disagree with our reading of the purpose of the appeals process. I think that if the IESG is in broad agreement on this point, reopening and rewording the response would not be an effective use of time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Representation of end-users at the IETF
At 12:34 PM +0200 9/21/07, Patrick Vande Walle wrote: I founded an ISOC chapter some years ago among others to see how users could provide input to the standards development process. However, there is no mechanism to consult, collect and present such information in an organized way. You could say that, as an ISOC trustee, I would need to submit a proposal to the board, and this is exactly what I intend to do. Great! Keep in mind though that those volunteers in chapters may expect that some consideration and feedback is being given to their (sometimes non technical) comments. If they are by default considered irrelevant, hobbyist rubbish, this may kill the process in the egg. Maybe the proposal should come from someone less pessimistic than you, then. A good proposer would be someone who believes that they can bridge the disparate communities and is willing to participate in the bridging work, not just the work on one side of the bridge or the other. There are plenty of people at ISOC who have spent more than a decade working on both sides of the bridge. Part of the goal of this discussion, for me, is to see how the IETF community welcomes such a proposal. If I get the impression that it is not supported, I won't spend more time on it. Spending the time of an organization that is meant to be bridging the communities seems more worthwhile for everyone than asking one group to greatly expand its scope into areas where it has no particular skills. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
ideas getting shot down, ULA-C, etc. -- please move to the right list
All, First, I would like ask people to move the ULA-C discussion off the IETF main list. We have a chartered working group (IPv6; to change to 6MAN in the next couple of days) that has an official work item to look at ULA-C. The best way to progress the topic is to participate that WG's effort. Here's the list: https://www1.ietf.org/mailman/listinfo/ipv6 Second, where are we with ULA-C? It should be obvious from this and other discussions that we are very far from consensus. But that does not mean that we are giving up on the task! I think most people agree that ULA-Cs have potentially very useful properties. The question is whether we can make them happen, and whether the advertised benefits can actually be realized. Here's the plan for moving forward: 1) Write a document about the benefits and difficulties relating to ULA-Cs. This helps us avoid repeating the same arguments in e-mail, and making it easier for us to decide what the right path forward is. 2) Write an updated/new proposed solution draft. The proponents of ULA-C are not happy with the current document, so a new one is needed. Again, its better to have something in writing so that we can all look at it. 3) Further discussion on the 6MAN list. Please make these steps happen. If you have cycles please volunteer to help with documents etc to the IPv6 chairs. I would also like to take the opportunity to state that we do need to be very careful about interpreting the opinion of the IETF. We should not and we do not "shoot ideas down" through the opinion of a few loud participants. But at the same time, if most of us think an idea is bad, the IETF needs to be able to say no. Finally, it is important to distinguish lack of interest and active opposition; generally we should allow consenting adults to do what they want, unless we believe the Internet will be hurt somehow by this. Jari Arkko INT AD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ideas getting shot down
Eliot Lear wrote: there was something of a view that the whole point of MXes was for the MX relay to bridge between online and offline devices. It was well understood at the time that MANY more systems were in fact on the networks that you mentioned than were on the ARPANET. And I would even argue that there MXes solved a major problem, which was that there was that sites that sat on both UUCP and the Internet often times Got It Wrong with regard to the precedence of "!". The abstraction that MX provided made relaying behavior much more explicit. I think this was understood at the time. +1 UUCP, Bitnet, CSNet, oh and let's not forget Arpanet-to-Internet transition (FTP to SMTP mail)... Administrative boundaries are not just bookkeeping constructs. They can have fundamentla technical impact. Take, for example, exterior routing technology versus interior. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Response to appeal dated 22-June-2007
Ted: With great respect, I must disagree. The appeal says: "It is the position of the appellants that this removal violates the IETF process by which working groups are governed." This say to me that the appellants believe that Cullen Jennings violated IETF process by replacing the GEOPRIV WG Co-chairs at the time that he did so. I personally reread many BCPs as part of this appeal review, and I could not find any process that was violated by this action. You are correct that any action taken by an AD can be appealed. In particular, RFC 2026 states: All appeals must be initiated within two months of the public knowledge of the action or decision to be challenged. In this particular appeal, there is a lot of background information that describes events that happened outside of the two month window. These can only be taken as context for the actions under appeal. Russ At 11:49 AM 9/21/2007, Ted Hardie wrote: I believe this response (I hope inadvertently) appears to remove a valuable principle by which the IESG acted on appeals. I urge the IESG to reconsider the formulation of its response to the appeal to clarify the issues raised below. At 2:01 PM -0400 9/20/07, The IESG wrote: >IESG Response to the Appeal Against the Removal of the Co-chairs of the >GEOPRIV Working Group > > >Introduction > > This is the IESG response to the appeal by Randall Gellens, Allison > Mankin, and Andy Newton posted at: > > http://www.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf > > Cullen Jennings recused from all discussion of this appeal. > > The appeal raises three major points for the IESG to address: > > 1. The removal of the WG Chairs violates IETF process; > > 2. The actions taken interfered with the consensus process; and > > 3. There is a conflict of interest. > > The appeal also proposes a remedy. This response includes some > comments about the proposed remedy. > >1. The removal of the WG Chairs violates IETF process > > RFC 2418 says: > > Working groups require considerable care and feeding. In addition >to > general participation, successful working groups benefit from the > efforts of participants filling specific functional roles. The Area > > Director must agree to the specific people performing the WG Chair, > > and Working Group Consultant roles, and they serve at the >discretion > of the Area Director. > > Since all WG chairs "serve at the discretion of the Area Director," > they can be replaced at any time. The previous GEOPRIV WG co-chairs > were told about their removal in private before the public > announcement. This action was not required, but it is the most > polite way to handle the situation. Perhaps the public announcement > could have provided some rationale, but the authority to remove a WG > chair is clear. In this response, the IESG appears to have read the appeal to state that the removal of the chairs was not within the authority of the Area Director. The appeal statement: http://www3.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf does not support this reading. It does not say that Area Directors do not have the right to remove chairs, it says that the manner and timing by which this was done interfered with the consensus process inappropriately. The remainder of the IESG statement below appears to attempt to address the interference issue. But in choosing to highlight that all "WG chairs serve at the discretion of the Area Director", the IESG appears to be saying that the personnel decisions of an Area Director or the IESG are not subject to appeal. During the time I served on the IESG, it was a general guideline that *any decision* of an Area Director or the IESG was subject to appeal to the IESG. While this is a broad reading of RFC 2026, Section 6.5, I think it is an important point and a principle worth retaining. The appeals process in the IETF is not simply a mechanism for establishing who has what rights; it is a mechanism for conflict resolution. By making all decisions subject to it, we ensure that conflicts which arise are dealt with as early as possible and with as little process as possible. If members of the community believe that a personnel decision was made in a way the interfered with the proper operation of the IETF, I believe asking the IESG to attempt to resolve the conflict is an appropriate thing to do. This appeal response, which re-asserts the authority of the AD to make the original decision, does not seem to support this use of the IETF's normal conflict resolution mechanism. Further, this appeal response appears to say that the only conflict resolution mechanism open to those who disagree with a personnel decision is to invoke one of the removal mechanisms for those who made it. I hope that the IESG will re-structure its response to this appeal to re-affirm that the conflict resolution mechanisms of the IETF are ava
RE: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Seems to me that what you are saying amounts to the statement that PI space cannot exist by definition. If there is address space that is routable on an Internet-wide basis it is by definition routable Internet space and no PI space. If someone needs such space they need to obtain an IP address space allocation and persuade their ISPs to route it. The question of whether this is possible is a policy issue, not a technical issue. Whatever the policy status (people disagree as to what the situation is) it is clearly not going to be solved by a technical hack that does not address the underlying political constraints. > -Original Message- > From: Fred Baker [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 20, 2007 4:35 AM > To: IETF-Discussion > Subject: Re: ULA-C (Was: Re: IPv6 will never fly: ARIN > continues to kill it) > > > > owners of those services will simply go to ISPs and say > "route this, > > or I'll find someone else who will". > > I'm actually not as convinced of this. Yes, they can get > routing from their ISP, and the ISP will be happy to sell it > to them. Can they get it from their ISP's upstream, and from > that ISP's downstreams? To make it into PI space in the usual > sense of the word, I think they wind up writing a contract > with every ISP in the world that they care about. > > I think ULAs will exceed the bounds of a single > administration, but they will do so on the basis of bilateral > contract, not general routing. > > ___ > 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: IPv6 will never fly: ARIN continues to kill it
Stephen Sprunk wrote: SCO had "deep" pockets too. IBM, Novell, etc. had much, much deeper pockets. Do you really think ARIN or ICANN could take on titans such as GE, IBM, AT&T, Xerox, HP, Apple, Ford, Halliburton, Eli Lilly, Prudential, and Merck? Even _one_ of them? ARIN would be squashed like a bug. Not to mention the entire weight of the USG if ARIN tries to mess with _their_ 13 /8s. I'm confident that the RIRs' membership would oust any leaders that knowingly got them engaged in significant litigation of this sort. I would largely agree with what you wrote, but put it another way: deep pockets are an incentive and not a deterrent. Someone who has no money is said to be judgment proof (heh - sort of like SCO right now ;-). Eliot ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Geopriv] Response to appeal dated 22-June-2007
At 1:16 PM -0400 9/21/07, Russ Housley wrote: >Ted: > >With great respect, I must disagree. The appeal says: "It is the position of >the appellants that this removal violates the IETF process by which working >groups are governed." This say to me that the appellants believe that Cullen >Jennings violated IETF process by replacing the GEOPRIV WG Co-chairs at the >time that he did so. I personally reread many BCPs as part of this appeal >review, and I could not find any process that was violated by this action. Russ, With equal respect, that statement is part of a much larger context, and I think your reading is too narrow. The immediately prior paragraph says, to take one piece of context out: >In summary, the Co-chairs of the GEOPRIV working group conferred via telephone >with >Cullen Jennings regarding irregularities of the GEOPRIV session at IETF 68. Mr. >Jennings participated in the discussion (detailed below) and at the very end >of the >call, indicated that he desired to remove the Co-chairs. This was interpreted >as a >type of threat. The Co-chairs then published a message to the GEOPRIV mailing >list >describing the irregularities of the GEOPRIV meeting at IETF 68, specifically >in order >to ensure that IETF process would be followed for the WG. Following this >message, >Mr. Jennings sent a strongly worded message to the IETF list, and he removed >the >Co-Chairs. This removal occurred during the time period when the Co-chairs were >seeking mailing list consensus on the items discussed during the GEOPRIV >session at >IETF 68. The working group chairs are charged in our process with determining consensus of working groups. If an AD removed working group chairs *in order to ensure that a specific determination were made*, that would clearly be contrary to the way the IETF is meant to work, no matter what the AD's baseline prerogatives for determining personnel would be. (Note that I am not saying that this what happened here, but this is a point where the issue raised would be salient). That action would be fundamentally a violation of the process for determining working group consensus, as the AD would be ensuring a specific consensus call by putting in someone willing to make that determination. An appeal response by the IESG that said that they did not believe that this is what happened in this case seems to be what you intended (at least based on Sam's response). I must repeat, however, that this response appeared to me to focus instead on the baseline prerogative of the AD over that issue. >You are correct that any action taken by an AD can be appealed. In >particular, RFC 2026 states: > > All appeals must be initiated within two months of the public > knowledge of the action or decision to be challenged. > >In this particular appeal, there is a lot of background information that >describes events that happened outside of the two month window. These can >only be taken as context for the actions under appeal. I appreciate your restatement of the important point that any action taken by an AD can be appealed, as well as Sam's personal statement to the same effect. If you are not willing to consider re-stating this appeal, a short statement by the IESG to that effect would be welcome. As it stands, statements by individual IESG members have no binding effect on later IESGs and the community is not necessarily notified when the interpretations change. As a concrete suggestion: "The IESG re-affirms that its reading of RFC 2026 is that any action made by an Area Director or the IESG may by made the subject of the conflict resolution mechanisms set out in Section 6.5 of RFC 2026. The IESG further wishes to highlight that the primary aim of the appeals mechanism set out there is to resolve conflicts and move the IETF as a whole towards consensus, and it urges all participants to approach them in that light." regards, Ted >Russ > > >At 11:49 AM 9/21/2007, Ted Hardie wrote: >>I believe this response (I hope inadvertently) appears to remove a valuable >>principle by which the IESG acted on appeals. >> >>I urge the IESG to reconsider the formulation of its response to the appeal >>to clarify the issues raised below. >> >> >>At 2:01 PM -0400 9/20/07, The IESG wrote: >>>IESG Response to the Appeal Against the Removal of the Co-chairs of the >>>GEOPRIV Working Group >>> >>> >>>Introduction >>> >>> This is the IESG response to the appeal by Randall Gellens, Allison >>> Mankin, and Andy Newton posted at: >>> >>> http://www.ietf.org/IESG/APPEALS/IESG_Appeal_20070622-final.pdf >>> >>> Cullen Jennings recused from all discussion of this appeal. >>> >>> The appeal raises three major points for the IESG to address: >>> >>> 1. The removal of the WG Chairs violates IETF process; >>> >>> 2. The actions taken interfered with the consensus process; and
Re: Vendor viewpoint on ULA filtered-by-default
On 21-sep-2007, at 17:56, Fred Baker wrote: There is an obvious inherent bug in that, which has been observed in the IPv4 Internet with respect to RFC 1918 and martian prefixes. Administrations that don't apply the policy to deny ULAs will accept them, which will have the effect of leaking them if the peer inadvertently advertises them. The problem is that we, as a vendor, can't really tell the difference between clueful operators and clueless ones (their money all looks the same), and as a result make no attempt to save the world from one while trying to satisfy the other. As a long time user of Cisco products, I think this is a useful approach. I would be quite upset if I found out that I couldn't use some kind of private addressing in a training course. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 20-sep-2007, at 21:19, Stephen Sprunk wrote: Sometimes ignoring a problem really does make it go away. Install a workaround, on the other hand, and the brokenness remains non-obvious so it persists. If often persists whether it remains non-obvious or not. I can't count how many hotels I've visited where I have to disable v6 on my laptop for v4 DNS to work Yes, hotels are the worst. In Chicago two months ago they used a NAT timeout in my hotel that was so short that my SSH, IMAP and IM sessions timed out every few minutes. Same problem with most WiFi hotspots; I think they use the same all-in-one boxes for HTTP-interception, DNS, DHCP, etc. There are few vendors in that space whose boxes _aren't_ broken in myriad different ways. Operators don't care because they've already gotten your money by the time you discover the brokenness. because their boxes break horribly when confronted with an lookup. This has been going on for _years_ and the operators and vendors obviously don't care even though the problem is blatantly obvious. Obviously this should be fixed. But: you may ask yourself: why is your system doing lookups when you obviously don't have IPv6 connectivity? Anyone from Microsoft listening? I suppose, in theory, a DNS query over v4 might return an record that _is_ accessible via one of my link-local addresses or the loopback address. As long as v6 is _enabled_ on a Windows box, it does queries, even if it has to send them via v4. I'm told WinXP isn't even capable of doing DNS over v6. I'm not advocating going around and breaking implementations that don't fully conform with specs on purpose, but if doing the right thing means that out-of-spec implementations see some problems, I can usually live with that. Whether I can live with that in a particular case depends on what percentage of the userbase will see "some problems" if that brokenness is exposed. Ah yes, the "if enough people do something wrong it becomes right" doctrine. So here in Holland we have "alcohol free" beer that contains 0.5% alcohol, and megabytes are now 100 bytes. That complaint doesn't resonate so well when you're writing in a language whose "rules" are defined by whatever people do and if enough people do something "wrong" it gets reclassified as "right". There's a difference between de jure and de facto standards. That's not to say that de jure standards are not needed -- they obviously are -- but when the majority of people are ignoring them, you can't just stick your head in the sand and ignore the de facto reality. That _should_ be a sign that the de jure standards need rewriting after one reviews _why_ the de facto standard has diverged. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ideas getting shot down
--On Wednesday, 19 September, 2007 19:42 +0200 Eliot Lear
<[EMAIL PROTECTED]> wrote:
> Here our views of history differ. I can't say that I had a
> gray beard at the time, nor that I was at all involved in the
> design, but I was there, and I think there was something of a
> view that the whole point of MXes was for the MX relay to
> bridge between online and offline devices.
As well as to intermittently or poorly-connected Internet
devices (the notion of backup via a host that was more able to
dependably reach the destination was well-understood too).
> It was well
> understood at the time that MANY more systems were in fact on
> the networks that you mentioned than were on the ARPANET. And
> I would even argue that there MXes solved a major problem,
> which was that there was that sites that sat on both UUCP and
> the Internet often times Got It Wrong with regard to the
> precedence of "!". The abstraction that MX provided made
> relaying behavior much more explicit. I think this was
> understood at the time.
Very well understood by just about everyone involved, often by
everyone on both sides of the gateways. It is also the reason
why wild-card MXs ("route to this machine to reach all sites in
that university or country") were so important.
john
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to appeal dated 22-June-2007
Ted: To begin with, I want to say that I agree with your perception of the appeal process. It is an important conflict resolution tool. The first thing that was done in the drafting of the appeal response was to list each of the claims in the appeal. That is why the introduction lists them: 1. The removal of the WG Chairs violates IETF process; 2. The actions taken interfered with the consensus process; and 3. There is a conflict of interest. The appeal response addresses each of these points with much more attention to number 2. I must repeat, however, that this response appeared to me to focus instead on the baseline prerogative of the AD over that issue. I agree, the response to the first point, which was focused on the sentence that I quoted from the appeal in my previous message, was a reading on whether the act of replacing the GEOPRIV WG co-chairs violated IETF process or not. However, the response to the second point, I believe, addresses the rest of the paragraph that you quoted. >You are correct that any action taken by an AD can be appealed. I appreciate your restatement of the important point that any action taken by an AD can be appealed, as well as Sam's personal statement to the same effect. If you are not willing to consider re-stating this appeal, a short statement by the IESG to that effect would be welcome. As it stands, statements by individual IESG members have no binding effect on later IESGs and the community is not necessarily notified when the interpretations change. I'd like to know if this is a topic of concern to people. As a concrete suggestion: "The IESG re-affirms that its reading of RFC 2026 is that any action made by an Area Director or the IESG may by made the subject of the conflict resolution mechanisms set out in Section 6.5 of RFC 2026. The IESG further wishes to highlight that the primary aim of the appeals mechanism set out there is to resolve conflicts and move the IETF as a whole towards consensus, and it urges all participants to approach them in that light." I will put your proposed text on the IESG telechat agenda for consideration as an IESG statement. Russ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
Stephen Sprunk wrote: >> So? The RIRs and ICANN have deep pockets. > > SCO had "deep" pockets too. IBM, Novell, etc. had much, much deeper > pockets. Do you really think ARIN or ICANN could take on titans such > as GE, IBM, AT&T, Xerox, HP, Apple, Ford, Halliburton, Eli Lilly, > Prudential, and Merck? Even _one_ of them? ARIN would be squashed > like a bug. Not to mention the entire weight of the USG if ARIN tries > to mess with _their_ 13 /8s. All of which is moot. The amount of money it would cost to litigate this is irrelevant, because there's no way that taking this to courts could result in any relief for the Internet before IPv4 space is exhausted. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ideas getting shot down
You seem to be of the impression that whether something "works" is binary. If a hack "works" in some situations and breaks things in others, does it work or is it broken? Note that different people will come up with different opinions on whether the hack works or not, depending on what apps they run, their role (are they users, or application vendors whose market decreases and support costs increase when network operators put in these hacks?), and so forth. It has nothing to do with being a purist. A hack that causes a 1% failure rate is a lot more costly to some users than to others. That failure rate is low enough that ISPs can get into denial about whether the failure exists and refuse to fix it. But the users and application vendors suffer nonetheless. Here's the rule that should be followed: If your service or product doesn't adhere to the standards, you're responsible for whatever breakage results. Keith > What's this about NAT-PT being killed? I still see vendor literature > which mentions NAT-PT support. If it works, and it is implemented, > then people will use it. > > Same thing goes for Application Layer Gateways, i.e. proxies. > > I don't think any network operator is in the business of being an > IETF purist. It is desirable that hardware and software adheres to > standards but it is more important for them to *WORK*!!! And if there > is a standards vacuum, that will not stop deployment. > > --Michael Dillon > > ___ > 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: ULA-C (Was: Re: IPv6 will never fly: ARIN continues to kill it)
Hallam-Baker, Phillip wrote: > Seems to me that what you are saying amounts to the statement that PI space > cannot exist by definition. If there is address space that is routable on an > Internet-wide basis it is by definition routable Internet space and no PI > space. > There can be such a thing as PI space that is treated differently than PA space. But anyone who thinks that having a PI prefix means that his prefix advertisements will be accepted in perpetuity by every IPv6 network is deluded. Sooner or later, you're going to have to pay _somebody_ to get that prefix routed. And the amount may well increase over time, perhaps drastically. And if you don't keep making those payments you're not going to be reachable anymore. So you can pay your ISP for PA space (along with connectivity) or you can pay somebody else (maybe many somebodys) for PI space in everyone's routing table. In either case you should design your network to be able to renumber in case you want to change who you're doing business with, or are forced to change your prefix. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to appeal dated 22-June-2007
At 3:49 PM -0400 9/21/07, Russ Housley wrote: > >>As a concrete suggestion: >> >>"The IESG re-affirms that its reading of RFC 2026 is that any action made by >>an Area >>Director or the IESG may by made the subject of the conflict resolution >>mechanisms >>set out in Section 6.5 of RFC 2026. The IESG further wishes to highlight >>that the primary >>aim of the appeals mechanism set out there is to resolve conflicts and move >>the IETF >>as a whole towards consensus, and it urges all participants to approach them >>in that light." > >I will put your proposed text on the IESG telechat agenda for consideration as >an IESG statement. > Thank you; I look forward to hearing the IESG's response. regards, Ted Hardie ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
