Comparison of ICAP and SOAP
HI, All Where can I find some materials or dicussion on ICAP and SOAP? I think both of them address somewhat the content adapation problem in Internet. Thanks. Wanghong
Re: I am *NOT* a believer in the democratic process.
In a consensus-oriented decision-making framework everybody with an opinion would work together to find some mutually acceptable (not loved - acceptable) accomodation, whether it's sending the work off to another standards body or modifying the charter and having the work done in the IETF. That hasn't been the ways things have worked during my short time with the IETF - noise is made and the IESG goes off to think about it, work directly with interested parties, and then make a decision. Maybe it's not that meaningful for us to be talking about consensus or direct voting when what we've really got is a republic. For better or worse, we've never claimed to use consensus-based decision-making for deciding whether a working group gets created. We do require that there be a significant show of interest for doing that group's work, but other than that, our process leaves those decisions to IESG and IAB. One of the presumptions behind the choice of consensus-based decision-making even for working groups is that the people making the decision are technically competent. Sometimes, the people proposing a new working group are unable to demonstrate technical competence, which makes their proposals quite dubious indeed. In such a case, the right thing to do is to send them elsewhere, but you'll never reach consensus with them about that. Keith
Re: I am *NOT* a believer in the democratic process.
Keith -- I beg to differ. There are a number of other groups that have considered taking their work to the IETF, but decided instead to just use the IETF WG Processes, as described in the relevant RFCs. They have done this with good results, and I recommend often that this be done by others. One of the benefits of this approach is complete avoidance of what is going on here in this mailing list;-)... So, the answer is, if you want to do it the IETF way, then just use the WG working rules, and take the results to the IETF when you are done, if the results look good enough. The only other reason to take work to the IETF is because you might draw in some additional useful talents from meeting attendees, and something then could rub off on your work. But otherwise, there are no particular inhibitors. IETF even allows outsiders to post IETF-DRAFTS, which serve to inform the larger IETF community about such non-IETF work. All this add to the over all value of the work being done. So, I read this mass of IETF mail to mean that the OPES work is just not ready for prime time, and so they should just settle down and get to work on making it ready for IETF prime time, or just do the work and be done with it. The thing I marvel at is the size of the fuss about the question;-)... Surely the readers of this list will not be offended by a few messages announcing the work! That would beat the pants off what we see here now;-)... Cheers...\Stef At 10:52 -0400 25/06/01, Keith Moore wrote: In a consensus-oriented decision-making framework everybody with an opinion would work together to find some mutually acceptable (not loved - acceptable) accomodation, whether it's sending the work off to another standards body or modifying the charter and having the work done in the IETF. That hasn't been the ways things have worked during my short time with the IETF - noise is made and the IESG goes off to think about it, work directly with interested parties, and then make a decision. Maybe it's not that meaningful for us to be talking about consensus or direct voting when what we've really got is a republic. For better or worse, we've never claimed to use consensus-based decision-making for deciding whether a working group gets created. We do require that there be a significant show of interest for doing that group's work, but other than that, our process leaves those decisions to IESG and IAB. One of the presumptions behind the choice of consensus-based decision-making even for working groups is that the people making the decision are technically competent. Sometimes, the people proposing a new working group are unable to demonstrate technical competence, which makes their proposals quite dubious indeed. In such a case, the right thing to do is to send them elsewhere, but you'll never reach consensus with them about that. Keith
Re: I am *NOT* a believer in the democratic process.
Keith -- I beg to differ. There are a number of other groups that have considered taking their work to the IETF, but decided instead to just use the IETF WG Processes, as described in the relevant RFCs. Indeed they have. But that's orthogonal to the point I was making. So, the answer is, if you want to do it the IETF way, then just use the WG working rules, and take the results to the IETF when you are done, if the results look good enough. No, that would be sheer lunacy. Because it's quite often the case that such work: - either doesn't consider the problem from enough different points of view, or - suffers from a lack of technical competence, or - was actually developed in a (semi-)closed environment in order to favor certain stakeholders over others It's one thing to say that other groups would do well to use certain parts of the IETF process, quite another to say that IETF should endorse the work of other groups. Keith
Re: I am *NOT* a believer in the democratic process.
stef: Keith -- I beg to differ. There are a number of other groups that have considered taking their work to the IETF, but decided instead to just use the IETF WG Processes, as described in the relevant RFCs. Indeed they have. But that's orthogonal to the point I was making. stef: So, the answer is, if you want to do it the IETF way, then just use the WG working rules, and take the results to the IETF when you are done, if the results look good enough. No, that would be sheer lunacy. Because it's quite often the case that such work: - either doesn't consider the problem from enough different points of view, or - suffers from a lack of technical competence, or - was actually developed in a (semi-)closed environment in order to favor certain stakeholders over others It's one thing to say that other groups would do well to use certain parts of the IETF process, quite another to say that IETF should endorse the work of other groups. COOK: good lord keith Surely stef's whole point is that the Area Directors, IESG, and IAB need only accept work that WAS good enough from THEIR own point of view. it sounds like you are saying that it simply is not possible to construct anything that could even merit IETF review unless you did the construction from scratch within all the channels of the IETF? If so it sounds like you are determined to keep the views of the current AD's, IESG and IAB as a gate through which ALL ideas must pass and are saying that it is flat out impossible for anyone to develop working code that could pass the scrutiny test. How do you know until, you see it? sounds to me like doctrinaire rigidity. Keith -- The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone fax) [EMAIL PROTECTED] Index to 9 years of the COOK Report at http://cookreport.com From now through Sept 30th half price sale on university library site license and access to ALL back issues. Site license $575 and all back issues $300. http://cookreport.com/sale.shtml
Re: I am *NOT* a believer in the democratic process.
But, more to the point, I am referring to the general reticence of non-IETF groups to use the IETF methods and processes in their own work related to developing standards for code for use on the Internet. However, I know of a few others that have adopted the IETF WG processes, and I consider this a good thing to be happening. In fact, I strongly encourage it. And even lead the charge from time to time. stef - historically, the ietf process worked because it was well-suited to the competence of the personalities involved. adopting ietf-like processes may be necessary, but it isn't sufficient, unless, of course, adopting ietf-like processes introduces a darwinian selection for the historical ietf-like personalities. ymmv. mo and lloyd have made several cogent arguments explaining the current disconnect, viz. the opes stuff. of course, opes isn't to blame, per se, this is just the latest instance of a mismatch of expectations. perhaps, as noted earlier, the turning point was when wg's were chartered to do requirements documents instead of protocol documents. perhaps the problem is even earlier... /mtr
Re: I am *NOT* a believer in the democratic process.
COOK: good lord keith Surely stef's whole point is that the Area Directors, IESG, and IAB need only accept work that WAS good enough from THEIR own point of view. it sounds like you are saying that it simply is not possible to construct anything that could even merit IETF review unless you did the construction from scratch within all the channels of the IETF? No, I'm only saying that it's wrong to encourage people to do their work independently of IETF if they want/expect IETF to endorse it. When other groups do standards work, that work should bear the name of the group that did the work. IETF's name should not be used to lend credibility to other groups. If so it sounds like you are determined to keep the views of the current AD's, IESG and IAB as a gate through which ALL ideas must pass and are saying that it is flat out impossible for anyone to develop working code that could pass the scrutiny test. Not at all. I'm just saying that we shouldn't call it IETF work when it's done elsewhere. Keith
Re: I am *NOT* a believer in the democratic process.
COOK: good lord keith Surely stef's whole point is that the Area Directors, IESG, and IAB need only accept work that WAS good enough from THEIR own point of view. it sounds like you are saying that it simply is not possible to construct anything that could even merit IETF review unless you did the construction from scratch within all the channels of the IETF? No, I'm only saying that it's wrong to encourage people to do their work independently of IETF if they want/expect IETF to endorse it. When other groups do standards work, that work should bear the name of the group that did the work. IETF's name should not be used to lend credibility to other groups. OKnow to me at least your answer is clear and much harder to quibble with.. but did i misunderstand steff? thought he was suggesting that work developed outside could be brought to the IETF structure that was well baked and mature and that the keepers of the structure might at least want to entertain the possibility that it could be scrutinized and that, if found worthy, an IETF blessed version emerge? If so it sounds like you are determined to keep the views of the current AD's, IESG and IAB as a gate through which ALL ideas must pass and are saying that it is flat out impossible for anyone to develop working code that could pass the scrutiny test. Not at all. I'm just saying that we shouldn't call it IETF work when it's done elsewhere. Keith -- The COOK Report on Internet, 431 Greenway Ave, Ewing, NJ 08618 USA (609) 882-2572 (phone fax) [EMAIL PROTECTED] Index to 9 years of the COOK Report at http://cookreport.com From now through Sept 30th half price sale on university library site license and access to ALL back issues. Site license $575 and all back issues $300. http://cookreport.com/sale.shtml
Re: I am *NOT* a believer in the democratic process.
Brian Lloyd wrote: [..] The protocol by WG committee approach espoused by the current IETF does not always produce good work. The concept of a Working Group Committee is revealing. gja
Going elsewhere (was: Re: I am *NOT* a believer...)
At 11:57 AM 6/25/2001, Jeffrey Altman wrote: There is no reason for a protocol whose authors plan to seek IETF backing to be developed outside the IETF. Unless some vocal people have told them that - their efforts are misguided - they're stupid and incapable of coming up with anything good - Because I can't see a use for it, it shouldn't be done - Because it could possibly be misused, it shouldn't be done - Because I didn't think of it first, it shouldn't be done (no one actually says this, however... - Because I don't have time to participate, it shouldn't be done (ditto) ... or any of a thousand other things... If enough crap is thrown in the way of people who want to accomplish things, eventually, they will find another way. Of course, what will happen if the OPES folks do as some suggest and develop it outside of the IETF (because they're frustrated with responses like have been exploding on here the last few days) and then try to bring it in for approval, then everyone is going to explode and say Why wasn't this work done in the context of the IETF? Hmmm... Guess you just can't win Another disturbing observation... in the past, every organization that really was a meritocracy (as I would call it) that I have been associated with, simply consisted of good people doing good work, without consideration for the rules of participating or keeping the riff-raff out, etc. There was no discussion of it being a meritocracy, it just was. As soon as it got to the point where people were calling it a meritocracy, and debating rules about what was meritous enough to warrant admission and who owned what piece of technological ground, it was the beginning of the end. Soon, the people who were doing the good work went elsewhere where they could once again do good work, unencumbered by the meritocracy. Stephen Stephen McHenry VP, Engineering/CTO Cacheware, Inc. 655 Campbell Technology Pkwy, Suite 150 Campbell, CA 95008 Ph: (408) 540-1310 Fax: (408) 540-1305 e-mail: [EMAIL PROTECTED] www.cacheware.com
Re: I am *NOT* a believer in the democratic process.
Does the IETF use the protocols it designs ? Do these incompetent Working Groups you refer to use IPv6 ? Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html - Original Message - From: Keith Moore [EMAIL PROTECTED] To: Marshall T. Rose [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; Einar Stefferud [EMAIL PROTECTED]; Marshall Rose [EMAIL PROTECTED] Sent: Monday, June 25, 2001 3:06 PM Subject: Re: I am *NOT* a believer in the democratic process. perhaps, as noted earlier, the turning point was when wg's were chartered to do requirements documents instead of protocol documents. perhaps the problem is even earlier... in my experience, one reason that a WG is chartered to do only a requirements document (there are others *) is that the WG appears to lack basic competence, but there isn't the political will to entirely block creation of the group. so the group is allowed to do a requirements document in the hope that doing so will give the group more clue. sometimes it even works, but quite often the group ends up creating an immensely complex mess. so the chartering of groups to do requirements documents may be a symptom of the problem rather than the problem itself. but it probably does correleate in time with the turning point. Keith * another reason is that the group's work needs to satisfy such a diverse set of interests that the only way to get everyone on the same page is for the group to jointly write such a document. p.s. I wish we'd stop calling them requirements documents, because we tend to treat them as if they were carved in stone rather than merely an exercise in getting everyone to agree on a problem definition. design goals is much better.
Re: Going elsewhere (was: Re: I am *NOT* a believer...)
Stephen McHenry wrote: [..] Soon, the people who were doing the good work went elsewhere where they could once again do good work, unencumbered by the meritocracy. An alternative interpretation is that the good people started being surrounded by less-good people who couldn't understand why their less-good ideas weren't being praised and glorified. To explain why less-good ideas weren't being praised simply for existing, the good people's behavior is described as a meritocracy. And if the less-good people don't deal with that reality very well, the good people go elsewhere to once again do good work, unencumbered by the need to explain themselves as a meritocracy. gja
Re: I am *NOT* a believer in the democratic process.
Well;-)... A really good discussion has occurred;-)... Gordon and Brian got it right in terms of my intentions. Let me clarify. Keith's fear of IESG being besieged with requests for IETF adoption of any work done outside the IETF without a WG Review is bogus as long as all work to be adopted must go through THE IETF WG process before it gets to the IESG. But, to suggest that it must never have been worked on elsewhere, if you want the IETF to bless it, is a perfect example of my concern about the IETF Skin (i.e., Protective Membrane) getting in the way of progress. All you are really arguing about is whether the OPES BOF GROUP can have meeting space at the IETF meeting, not whether or not they can work on it elsewhere and bring the work forward when it is more fully baked. Of course they can work on it anywhere they want, and time that they want. But, the attitude displayed here clearly says that one should do it all inside the IETF! Now, if this quote is not what Keith and others mean to convey, now is the time to correct the misinterpretations I and others are getting... Of course, this notion of do it all here carries with it the right and ability of the IETF to control and regulate what is even discussed in other circles. I am certain that this is an unintended consequence of the passage of time and circumstances, and that the result is clearly not desired. But there it is! I agree that the points of confusion in this thread are subtle, and perhaps easily missed, but I have been observing the effects of the IETF skin (actually a pretty tough hide!) for many years now, going back to before the Boston Tea Party was held at the MIT IETF in 1992, and what I am seeing is a return to the pre-Tea Party days, when IETF had gravitated to a top-down control scheme, with a toughening hide. It is interesting how such skin is mostly invisible to people inside organizations. Of course, it is because the hide is protecting them from being bothered by or distracted by what is being blocked. And, in the end, lots of people have come to see the IETF as being aloof or even hostile to many aspects of the internet. I would name some, but I do not want to derail this discussion into an open discussion of those areas when it is the higher meta level problem that has surfaced here. My hope is that all the smoke you are seeing here is a sign of a real fire that needs to be addressed. My specific interests have no place in this discussion. Cheers...\Stef PS: This is not the only case of organizational skin getting in the way of desired progress! I see it in many volunteer groups that desperately want others to join, but which just cannot see how their skin is blocking the entrances...\s At 12:01 -0700 25/06/01, Brian Lloyd wrote: At 10:27 AM 6/25/2001, you wrote: So, the answer is, if you want to do it the IETF way, then just use the WG working rules, and take the results to the IETF when you are done, if the results look good enough. No, that would be sheer lunacy. Hmmm. Seems to me that Stef speaks sense. Because it's quite often the case that such work: - either doesn't consider the problem from enough different points of view, or Then they request for comment and get feedback from others interested in the same problem. Isn't that how all this got started? - suffers from a lack of technical competence, or Assuming automatically that someone from outside the IETF is incompetent is just as arrogant as assuming that someone inside the IETF is competent. Even the work inside the IETF sometimes suffers from a lack of technical competence. Cluefulness is not a prerequisite for attending an IETF meeting or attempting to participate in a WG. No, the playing field is pretty level here. We put up with cluelessness at the IETF because there is no metric for cluefulness that we can engage ahead of time. You bring in the whole stalk of wheat and separate the wheat from the chaff in the threshing process. I see entirely too little threshing going on in the IETF these days. I think we worry to much that people will get their little feelers hurt. - was actually developed in a (semi-)closed environment in order to favor certain stakeholders over others That does not preclude the work from containing the seeds of good ideas. Good ideas come from individuals, not from committees or organizations. The IETF doesn't have a lock on good ideas. If a solution applies to a subset of a problem it may have application to the larger problem and/or it may trigger something in someone else's mind to come up with the general solution. Developing it within the committee doesn't guarantee anything. It's one thing to say that other groups would do well to use certain parts of the IETF process, quite another to say that IETF should endorse the work of other groups. The IETF should endorse good work no matter where it
Re: Comparison of ICAP and SOAP
In a nutshell: ICAP is a means of encapsulating HTTP inside of HTTP, to allow messages to be 'vectored' from an intermediary to an ICAP server for processing, and then sent on their way. It also defines where those messages may be vectored from the intermediary. I believe that its primary design goal is efficiency, but that's different depending on who you talk to. SOAP can IMHO best be thought of as an XML messaging convention, with some protocol-like attributes (such as the RPC convention). SOAP is designed to be transport-dependant; while its most common use is across HTTP, it can be used with other underlying protocols like SMTP or raw TCP. SOAP is designed to allow targetting of blocks of the XML to be processed by specific intermediaries. Its primary use cases are 'Web Services', i.e., the machine-machine Web, e.g., stock quote services, order queuing, etc. So, SOAP could be used to implement ICAP, but then again so could BEEP. Not too many of the ICAP people are interested in using SOAP, though, as their requirement is to allow 'wire-speed' vectoring and processing, and they find the overhead of XML unacceptable. Cheers, On Mon, Jun 25, 2001 at 04:11:01PM +0800, Wanghong Yuan wrote: HI, All Where can I find some materials or dicussion on ICAP and SOAP? I think both of them address somewhat the content adapation problem in Internet. Thanks. Wanghong Speaking for myself, -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA)
Re: I am *NOT* a believer in the democratic process.
I think that the meta issues under discussion here will not be helped by diverting discussion to IETF evaluation of my specific examples. The work often involves some kind of controversial issues, which would take us way off target. See below... At 20:20 +0100 25/06/01, Lloyd Wood wrote: On Mon, 25 Jun 2001, Einar Stefferud wrote: Keith -- I beg to differ. There are a number of other groups that have considered taking their work to the IETF, but decided instead to just use the IETF WG Processes, as described in the relevant RFCs. They have done this with good results, and I recommend often that this be done by others. which other groups have done so successfully, then? I will only identify these others in private messages, because I do not want this discussion thread to turn into a feeding frenzy over the the specific work that was done. Lets stick to the general meta issues. And, of course, some of them have not turned into adoptable results, which must be expected and not therefore used to fault the concept of using IETF tools outside the IETF, and perhaps bringing work to the IETF after beginning elsewhere. Failing to produce something useful in the IETF sense without bothering the IETF is not harmful to the IETF, and not a proper issue in this discussion. But otherwise, there are no particular inhibitors. IETF even allows outsiders to post IETF-DRAFTS, which serve to inform the larger IETF community about such non-IETF work. All this add to the over all value of the work being done. IETF allows _anyone_ to post an internet draft. Certainly, and I loudly applaud this fact. The only inconvenience I find with it is that the DRAFT publication process stops dead in advance of IETF meetings, which is unfortunate for anyone outside IETF who has a need to publish a draft during such times of power outage. It would really be nice if DRATS that are declared to not be related to the meeting could still be published without such interruptions. This is both a suggestion and a request, but not a demand. I do not know all the aspects of this practice. but, it is a part of the skin that encloses the IETF and protects it from outside influences. L. everyone's an outsider. But some are more outsider than others;-)... Maybe lots more;-)... [EMAIL PROTECTED]PGPhttp://www.ee.surrey.ac.uk/Personal/L.Wood/ Cheers...\Stef
Connecting IPv6 Routing Domains Over the IPv4 Internet
http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_routing.html Connecting IPv6 Routing Domains Over the IPv4 Internet by Brian E. Carpenter, IBM iCAIR Keith Moore, University of Tennessee Bob Fink, Energy Sciences Network --- Was this done inside the IETF ? Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html
a solution to the complexity problem
http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_routing.html The 6to4 transition mechanism, Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels [6] , provides a solution to the complexity problem of using manually configured tunnels by specifying a unique routing prefix for each end-user site that carries an IPv4 tunnel endpoint address. It should also be noted that each end-user site with as little as a single IPv4 address has a unique, routable, IPv6 site routing prefix thanks to the 6to4 transition mechanism. A solution to the complexity problem Is this an IETF solution to a complexity problem which the IETF created ? If the IETF is so cluefull, how could it create complex problems in the first place ? Does the IETF create problems and then find solutions elsewhere, and then claim to have also created solutions to complex problems ? -- thanks to the 6to4 transition mechanism thanks to the IETF ? Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html
Re: I am a strong believer in the democratic process.
[EMAIL PROTECTED] wrote: However, I still have difficulties to understand the merit of having .ip6.int or .ip6.arpa or even .mickey-mouse for holding the reverse records. That must be a 100 % political decision with no merit at all. Well... we *DO* need to agree on what the root of the reverse tree will be - otherwise it's hard to write tools that do reverse lookups. ;) Fine, I have no problem with that statement. The politics starts when you realize that somebody owns the spot that you're parking the tree. Using .mickey-mouse is bad - there's *enough* Bad Karma attached to the whole TLD issue via ICANN and the like. Sure, I also understand that there are many intercoursing manureholes around there (is this term polite enough :-) ? Using .ip6.int or .ip6.arpa requires that the manager(s) of .int or .arpa agree/consent/support that usage (which they may not, for a number of reasons). Looking at the SOA/NS entries for .INT and .ARPA is rather revealing. I'm pretty sure that the current set of NS entries for .INT is sufficient to support reverse lookups under the current level of IP6 deployment, but will require some major upgrading in the future. ;) Therefore, I believe that meritocracy is fine at a WG level. Unfortunately, it is not at the upper level like IESG and IAB. Worse, requiring an ICANN BoD candidate be highly technical skilled sounds like requiring Lou Gestner (IBM, an ex cookie manager, http://www.ibm.com/lvg/ ) to understand the inner beauty of an IBM 360/91 pipeline processor. Last, perhaps long time IETF participants (or whatever the political term is), should take a sabbatical term: life is not just reading emails (especially on weekends)! Visiting South Africa is a good idea, to study on how a minority gave up its long time domination. regards, -- Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org Get there in time:mirror on the wall-Genesis:tail -f trick
Re: I am *NOT* a believer in the democratic process.
http://www.dnso.org/clubpublic/ga-sys/Arc00/msg00136.html - Original Message - From: RJ Atkinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 25, 2001 7:48 PM Subject: Re: I am *NOT* a believer in the democratic process. It would be A Public Service if someone would setup a separate mailing list elsewhere for this thread so that we could return the IETF list to a normal mode. Perhaps the new list could be named ietf-politics, just to make the list's topics clear to all.
Re: Connecting IPv6 Routing Domains Over the IPv4 Internet
Yes it was. See the references at the end of the article you refer to. It clearly says that most of the documents were produced by the ngtrans working group of the IETF. Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office of the CTO, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Mon, 25 Jun 2001, Jim Fleming wrote: http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_routing.html Connecting IPv6 Routing Domains Over the IPv4 Internet by Brian E. Carpenter, IBM iCAIR Keith Moore, University of Tennessee Bob Fink, Energy Sciences Network --- Was this done inside the IETF ? Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html
Re: Connecting IPv6 Routing Domains Over the IPv4 Internet
Are these the references you mean ? [0] Fink, R., IPv6-What and Where It Is, The Internet Protocol Journal, Volume 2, No. 1, March 1999. [1] IPng and IPv6 information, including formal specifications, can be found at: http://playground.sun.com/pub/ipng/html [2] The Case for IPv6, an Internet Draft of the IAB, can be found at: http://www.6bone.net/misc/case-for-ipv6.html [3] IETF IPv6 Transition Working Group (ngtrans) information, including status of all its current projects, can be found at: http://www.6bone.net/ngtrans/ [4] Transition Mechanisms for IPv6 Hosts and Routers, RFC 1933, can be found at: http://www.ietf.org/rfc/rfc1933.txt [5] The 6bone IPv6 Testbed Network is explained at: http://www.6bone.net [6] Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels (6to4), an Internet Draft of the IETF ngtrans WG, can be found at: http://www.6bone.net/misc/6to4.txt [7] IPv6 Aggregatable Global Unicast Address Format, RFC 2374, can be found at: http://www.ietf.org/rfc/rfc2374.txt [8] Transmission of IPv6 Packets over IPv4 Domains without Explicit Tunnels (6over4), RFC 2529, can be found at: http://www.ietf.org/rfc/rfc2529.txt [9] Neighbor Discovery for IP Version 6 (IPv6), RFC 2461, can be found at: http://www.ietf.org/rfc/rfc2461.txt [10] IETF IPv6 Working Group (ipngwg) information, can be found at: http://www.ietf.org/html.charters/ipngwgcharter.html - Original Message - From: Ole J. Jacobsen [EMAIL PROTECTED] To: Jim Fleming [EMAIL PROTECTED] Cc: ietf@ietf. org [EMAIL PROTECTED] Sent: Monday, June 25, 2001 9:34 PM Subject: Re: Connecting IPv6 Routing Domains Over the IPv4 Internet Yes it was. See the references at the end of the article you refer to. It clearly says that most of the documents were produced by the ngtrans working group of the IETF. Ole Ole J. Jacobsen Editor and Publisher The Internet Protocol Journal Office of the CTO, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Mon, 25 Jun 2001, Jim Fleming wrote: http://www.cisco.com/warp/public/759/ipj_3-1/ipj_3-1_routing.html Connecting IPv6 Routing Domains Over the IPv4 Internet by Brian E. Carpenter, IBM iCAIR Keith Moore, University of Tennessee Bob Fink, Energy Sciences Network --- Was this done inside the IETF ? Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html
Re: I am *NOT* a believer in the democratic process.
On Mon, 25 Jun 2001 12:01:03 PDT, Brian Lloyd said: threshing process. I see entirely too little threshing going on in the IETF these days. I think we worry to much that people will get their little feelers hurt. Send them my way. I'm renowned for my ability to tell almost anybody, in excruciating detail, exactly why their idea is dumber than a box of rocks. ;) So let 'em build their protocol, whatever it is, and bring it to the IETF. The problems with a really bad protocol can be extremely educational and entertaining. The elegance of a really good protocol can be extremely educational and entertaining. I don't see how we can lose. Actually, a Really Bad Protocol is usually dreadfully excruciatingly painful, unless somebody performs an MST on it. For those not familiar with it, see http://www.scifi.com/mst3000/ for the TV show, or http://brie.bmsc.washington.edu/people/merritt/books/Eye_of_Argon.html for an example of the concept. Now, maybe if we had more protocol reviews like that... ;) /Valdis
Need to do architecture. ???
- Original Message - From: RJ Atkinson [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, June 25, 2001 7:48 PM Subject: Re: I am *NOT* a believer in the democratic process. It would be A Public Service if someone would setup a separate mailing list elsewhere for this thread so that we could return the IETF list to a normal mode. Perhaps the new list could be named ietf-politics, just to make the list's topics clear to all. ftp://ftp.iab.org/in-notes/IAB/IABmins/IABmins.010508 12. IAB role/responsibilities Revisiting our role -- we're not an IESG oversight committee; we're not a politics body (no, really). Need to do architecture. Need to reach across layers/boundaries (which is sometimes hard; goes against grain). Perhaps the IAB could be the provoker of activities like writing up the APPS architecture, getting cross-pollination to happen. Harald: what is the picture that makes the pieces of architecture we're asked to develop hang together? Discussion has been interesting. Should follow-up on it; perhaps as an in-person discussion? Ran suggests we could talk about it in London, with a certain amount of pre-planning. London is a long time off, so we'll attempt to pursue on e-mail, as well. -- Jim Fleming http://www.unir.com Mars 128n 128e http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp http://www.ietf.org/mail-archive/ietf/Current/msg12213.html http://www.ietf.org/mail-archive/ietf/Current/msg12223.html
