Re: Reminder: Poll about restructuring options
Hi Dave, I am trying to imagine any sort of serious protocol development process that used that sort of logic and then had acceptance and/or success. Here-in lies the rub. If you try to use our rules of protocol development to develop an organization we'll never get there. And you and I agree that there are bigger fish to fry, and right now the kitchen is backing up. No, I'm not going to pick apart the rest of your message. I disagree with some of your points but aside from one point to John and perhaps a response to Mr. Raymond, I've had my say. Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Shuffle those deck chairs!
Dave Crocker <[EMAIL PROTECTED]>: > 1. Nothing about the reorganization is going to make IETF > standards be more useful or be produced significantly more > quickly. Hence, reorganization has nothing to do with the really > serious threats to IETF long-term survival. Indeed it does not. I've been lurking on this list for a couple of months now, and I am fighting an increasing feeling that I am watching deck chairs being rearranged on the Titanic. In the last 60 days, the IETF has taken the worst blow to its credibility that I have observed in the entire history of the organization. I refer, of course, to the Sender-ID debacle, which exposed IETF's inability or unwillingness to defend Internet standards against patent predation even when the existence of prior art is readily establishable. Here is what I had to say to Yakov Shafranovich on 7 September: I believe the IETF's stated policy of passivity in the face of IPR power grabs damages the IETF first and foremost. The whole point of having standards organizations is that they coordinate multiple competing interests to create a neutral commons that grows a market faster. No standards organization can long remain relevant if the net effect of its activities is not to do this but rather to rubber-stamp proprietary control, creating monopolies in slower-growing markets rather than commons in faster-growing ones. In times past, simply ignoring the more outrageous claims may have been enough of a response. I don't think it is today. Conditions have changed. Post-DMCA and with the USPTO interpreting the scope of patents ever more liberally, IPR law has more teeth than it used to and the perceived risk attached to ignoring IPR claims has escalated. Accordingly, any standards organization that wants to keep itself relevant (e.g., useful to multiple competing interests) can no longer merely describe a commons and piously hope nobody will fence off too big a chunk. It has to assert and actively defend that commons, signaling that no raids will be permitted there. Note that nothing in the previous two paragraphs is open-source ideology in any sense, just a straightforward discussion of signaling behavior in markets. I think you'd be hard put to find any economist that would disagree with it. The problems it raises are not unique to IETF; other technical-standards organizations such as W3C, NIST, and ISO are grappling with them as well. I consider the IETF part of the open-source community. While I certainly would not object if the rest of the open-source community's agenda were to affect IETF policy, I think the most pressing reasons for IETF to act are the effect of surrendering to IPR power grabs on the IETF's own viability. Accordingly, the question I think you should be asking is: can the IETF long survive a policy of simply ignoring IPR claims in the hopes they'll go away? You'll have to judge for yourself, but I think the answer is "no". As for the rest of the open-source community's position, I think that has been made very clear by the open letters from ASF, Debian and elsewhere. If IETF is not prepared to actively assert and defend a commons, then we have no choice but to write off the IETF as part of the problem rather than part of the solution and do the IETF's signaling job ourselves. Those responses were all about "no raids will be permitted here". That is what they *mean*, and IETF's authority took a bad hit from the fact that they had to be issued at all. I think it would be in everyone's interest for the IETF's standing not to be further eroded, and I think the authors of the open letters would agree. But for that good result to obtain, the IETF has got to get off its butt and take back the job of defending the commons. The *whole* job, including rejecting RAND terms and proprietary licensing. A month later, my assessment of the political damage the Sender-ID mess has done to IETF has only gone up. You are on a fast road to irrelevance, gentlemen. You'd best be thinking about how to change *that* rather than conducting meaningless exercises in rearranging your bureaucracy. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
> However, I don't see delay > at this point in time assisting our cause. In fact, the > general membership of the IETF (whatever that means) has very > few lawyers, and probably very few MBAs. One would have to > wait a LONG time for community consensus. 1. Nothing about the reorganization is going to make IETF standards be more useful or be produced significantly more quickly. Hence, reorganization has nothing to do with the really serious threats to IETF long-term survival. 2. The current sense of crisis has mostly come from a loss of revenue. Nothing about the reorganization will necessarily fix that. 3. The rest of the sense of crisis is due to interaction problems between some people in IETF leadership and some people in the organizations that the IETF uses for services. Nothing in the reorganization is certain to improve any of that, especially since we do not have precise statements of work for them. (There is a rather mystical sense that the reorganization will fix these issues, but in fact nothing in the simplistic, superficial way that we are proceeding should give us any sense that that improvement is likely. Quite the opposite.) 4. Most of the reorganization process has been pursued with partial statements, incomplete plans, and assertions of urgency. It certainly has not been conducted in a way that attended to concerns as they were raised. Quite the opposite. So the view that "delay" will not assist us amounts to a statement that we should not worry about the considerable range of serious problems in how we have been pursuing organization, or with our community ignorance about what we are doing, but we should charge ahead (blindly) just to get it over with. I am trying to imagine any sort of serious protocol development process that used that sort of logic and then had acceptance and/or success. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 [EMAIL PROTECTED] brandenburg.com ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
John, > In this context, my precise objection to what is going on now > rests on a comparison with that style of leadership. Jon's > style involved persuasion, logic, facts, and trying to > understand the point of view of those with whom he disagreed. > Like you, I disagreed with some of his positions and decisions, > and I found him quite stubborn when he thought he was right (not > always a bad trait), but I could almost always end up > understanding his point of view. By contrast, we are now seeing > a different style of position-taking and decision-making, one > that terrifies me. The new style involves assertions of the > "rights" of the people who occupy IESG and IAB seats (because > they are in those seats) instead of explanation and openness > with the community about details and options, and involves > (virtually) shouting "wrong" instead of engaging in discussion > and persuasion. Perhaps the IETF traditional motto, "rough consensus and working code" should be revised to make it clear that the "rough consensus" goes only up to a certain point, but after that point the IETF operates solely by a decree from the IESG. Yakov. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Re: Root Anycast (fwd)
On 2-okt-04, at 18:25, Paul Vixie wrote: nycast has worked very well. both inter-AS and intra-AS. the fact that a not-clueful-enough engineer *could* build a non-working topology using anycast and PPLB as ingredients, does not mean that anycast or PPLB are bad. it means you have to be clueful-enough before you use either tool. (and remember kids, all power tools can kill.) It's not as simple as that. It's possible for bad things to happen if: 1. some DNS server is anycast (TLD servers are worse than roots because the root zone is so small) 2. fragmented UDP packets or TCP are used as a transport 3. a network is built such that packets entering it through router X may prefer a different external link towards a certain destination than packet entering it through router Y 4. a customer of this network is connected to two different routers 5. the customer enables per packet load balancing All of these steps happen in the real world, and are in and of themselves not examples of bad engineering. However, the end result can be reduced connectivity to one or more anycasted DNS servers under some circumstances. (See my message to dnsop from yesterday http://darkwing.uoregon.edu/~llynch/dnsop/msg03105.html for more info, reformat using a non proportional font if necessary.) Now the question is: how do we deal with this? I don't think removing anycast wholesale makes sense and/or is feasible. Same thing for declaring per packet load balancing an evil practice. A better solution would be to give network operators something that enables them to make sure load balancing doesn't happen for anycasted destinations. A good way to do this would be having an "anycast" or "don't load balance" community in BGP, or publication of a list of ASes and/or prefixes that shouldn't be load balanced because the destinations are anycast. and they would know that PPLB is basically a link bundling technology used when all members of the PPLB group start and end in the same router-pair; It doesn't make much sense to have multiple links terminate on the same router on both ends as then both these routers become single points of failure. Often, the end sending out most traffic will have the links terminate on one router (so load balancing is possible) while the other ends of the links terminate on two or more routers. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
--On Monday, 04 October, 2004 18:33 +0200 Eliot Lear <[EMAIL PROTECTED]> wrote: > You know, Spencer. We *had* a king for a VERY long time, and > it was Jon Postel as RFC Editor and IANA. And somehow we > survived. While Jon was around somehow a vast plethora of > standards got vetted, not the least of which were IP, TCP, > UDP, ICMP, SMTP, FTP, SMTP, NNTP and DNS. I agreed with some > of his decisions and disagreed with others. Probably the same > would be true with Tim Berners Lee. Actually, Eliot, Jon had great powers of persuasion and influence based on technical skill, knowledge, accomplishments, and contributions. He has little formal authority wrt the standards process, and a huge amount of sense about not trying to intervene in areas where he lacked knowledge and competence. And I never saw any symptoms of, e.g., "because I am the occupant of the RFC Editor chair I have certain 'rights'". >From where I sit, that is a effective and appropriate style of leadership in an organization like the IETF. In this context, my precise objection to what is going on now rests on a comparison with that style of leadership. Jon's style involved persuasion, logic, facts, and trying to understand the point of view of those with whom he disagreed. Like you, I disagreed with some of his positions and decisions, and I found him quite stubborn when he thought he was right (not always a bad trait), but I could almost always end up understanding his point of view. By contrast, we are now seeing a different style of position-taking and decision-making, one that terrifies me. The new style involves assertions of the "rights" of the people who occupy IESG and IAB seats (because they are in those seats) instead of explanation and openness with the community about details and options, and involves (virtually) shouting "wrong" instead of engaging in discussion and persuasion. The comparison to W3C is really not fair, because they are organized along different principles. But, at the beginning, Tim could unilaterally either establish a recommendation or kill a proposal, could do so without giving an explanation, and was _expected_ to exercise the design judgment that implied. That is very different from the way the IETF has traditionally worked. > But you missed my point. Don't like the IETF or the W3C? Try > the TMF or the DMTF or the ITU or the GGF or the IEEE or roll > your own (everyone else has ;-). Sigh. Some of us have dedicated a rather large portion of our lives over the last decade or so to both trying to get some technical work done in the IETF and to keeping it productive in terms of producing high-quality, timely, well-documented, standards. Some of us are even deluded enough to believe that the process problems we see today are aberrations that can be corrected by explaining the problems and their implications to both the community and the leadership and calling for a different way to do things (or a return to most of the old way). Even though it increasingly feels like a losing battle and a waste of energy to try, I'd much rather see those who believe in leadership by either royal authority or strength of personality, in voting, and in membership structures go somewhere else. And I have the odd delusion that a fairly significant fraction of those who do the technical work around here prefer openness and consensus processes around here to having their comments dismissed with "WRONG". You have made contributions around here. If someone disagrees with you, would you prefer an exploration of the differences in perspectives or an assertion of "rights" and then being told "WRONG"? john ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [dnsop] Complaint about inappropriate behavior by Stephane Bortzmeyer
On Mon, 4 Oct 2004, John Brown wrote: > Copyright 2004, John Brown, All rights reserved, redistribution requires > prior written permission of the Author / Copyright Holder. > > Dean, > > I would say that per Section 7 that as a member I have actual knowledge > and thus offer the opinion that your actions on this and other lists > that I've seen you post to, does not enhance the list, does not add > value to the process. Instead your actions are clearly intended to > disrupt and distract. > > If it was up to me, I'd remove your account until such time as you > learned to play well with others. You are the one who can't make any other argument except name-calling. Name-calling does not enhance the list, and does not add value to the process. Name-calling disrupts and distracts attention from technical issues. Indeed, the original anycast discussion in 2002 was disrupted by name-calling and other attacks on Dr. Bernstein. Strangely enough, many of the same people are now attacking me. It is your actions that are __intended__ to disrupt and distract. Otherwise, you'd have technical arguments that didn't depend on personal attacks. --Dean > Copyright 2004, John Brown, All rights reserved, redistribution requires > prior written permission of the Author / Copyright Holder. > > > > Dean Anderson wrote: > > The following message by Stephane Bortzmeye includes an inappropriate > > personal attack in violation of the following sections of the ISOC Code of > > Conduct: http://www.isoc.org/members/codeconduct.shtml > > > > 7 Only offer or claim to offer opinions or services that lie within the > >member's actual knowledge or competence. > > > > 8 In the case of financial or material conflict between personal and > >professional interests, or between two professional interests, declare > >this conflict to all interested parties and if appropriate in public. > > > > 9 Respect the generally accepted norms of Internet etiquette for human > >communications, especially by avoiding communications that are false or > >are likely to be considered as discourteous, objectionable, malicious, > >unwanted, or causing unjustified loss of prestige. Avoid fraudulent or > >deceptive statements. > > > > 11 Treat all users and colleagues fairly and on equal terms. > > > > > > And the message violates the following sections of the IETF Guidelines for > > Conduct RFC 3184: > > http://www.ietf.org/rfc/rfc3184.txt?number=3184 > > > > 1. IETF participants extend respect and courtesy to their colleagues > > at all times. > > > > IETF participants come from diverse origins and backgrounds and > > are equipped with multiple capabilities and ideals. Regardless of > > these individual differences, participants treat their colleagues > > with respect as persons--especially when it is difficult to agree > > with them. Seeing from another's point of view is often > > revealing, even when it fails to be compelling. > > English is the de facto language of the IETF, but it is not the > > native language of many IETF participants. Native English > > speakers attempt to speak clearly and a bit slowly and to limit > > the use of slang in order to accommodate the needs of all > > listeners. > > > >2. IETF participants develop and test ideas impartially, without > > finding fault with the colleague proposing the idea. > > > > We dispute ideas by using reasoned argument, rather than through > > intimidation or ad hominem attack. Or, said in a somewhat more > > IETF-like way: > > > > "Reduce the heat and increase the light" > > > > > > > > > -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
I have been trying to be mostly in listening mode, but I'd like to provide my personal perspective on the process issues. 1/ Openness of process I don't mind having my mistakes pointed out, but I rather fear I'm being accused of not having lived up to a promise I didn't make. Here's what I actually said on August 27 (on this list -- anyone who wants the whole message can dig it up in the archives): "We are in agreement that key strategic decisions have to be made with the informed consent of the community. Harald and I have made the commitment to put as much on the table as is possible to have a rational open discussion that should come before that consent phase. That's the commitment that brought this document out, and it will continue to surface material input if, as, and when it comes to light. " And I'm comfortable in asserting this is what we've done. Have subsets of the IAB & IESG had discussions about this material? Yup. That's what brought us Scenario O and the revised Scenario C. To the list. For public discussion. Have there been other private discussions with various & sundry folk? Yup. And there will be more. Are we inking deals at private breakfast meetings? No. If, as, and when private discussions develop to a point that they can produce concrete material for discussion/impacting directions, we will put it out probably with a statement outlining how we see it fits into the discussional puzzle, and possibly with a recommendation for action on it. In my opinion, as someone who's been trying to walk the fine line between getting people informed to the point of being able to participate in decision discussions (without boring them to tears, as some folk evidently are...), and have something vaguely reminiscent of a convergent decision process, that's about as good as we can get. 2/ Qualifications of IAB/IESG members, [Ll]eadership The IAB & IESG members are selected to oversee/run parts of the IETF process. The folks I've seen in the roles take that responsibility pretty seriously. Apart from everything else, it means that they see more of the inner workings of the IETF process, because they have operational experience in trying to get stuff to happen within it, at a meta-level from what document editors and WG chairs do. They can tell when the processes aren't working. I argue further that they therefore have some sense of what changes would integrate into the functioning system. Does that make them MBA's? Nope. Does that make them god-like? Nope. In my opinion, that does make a reasonable filter function. That is -- we (IAB & IESG) have been collecting data from all over, including hired professional input (see, eg, Carl's document) and the IETF working community itself. We're weighing it, within the context of the above-stated responsibilities and perspectives. We've committed to putting it back out to the community in the shape of a recommendation that you can make sense of based on the raw data that you've got to hand. That means everyone gets a voice, though not a vote (the poll helped convince us that people are paying attention, even if they're not posting... that was real data for *us*, anyway!). So -- I do believe NomCom selected folks are able to credibly lead this process for change, as long as they know the boundaries of their own competences and solicit additional input where needed. I believe that's true for the overall process discussed here, and I personally believe it's the appropriate guiding principle for the role of the IETF & IAB Chair positions in any future organizational structures. Leslie. P.S.: Don't think I quite made the A4 limit... John C Klensin wrote: Eliot, I'm obviously not being successful at explaining what I'm concerned about it and my getting this deeply drawn into this whole discussion violates a promise I made to myself some time ago, which was to concentrate my IETF time on only those things in which I had a strong technical interest and was convinced would go somewhere. So, having posted the "clerk's office" note, which I think ought to be much more relevant and important than this one, I give up. Three parting observations: (1) I actually agree with the conclusion that seems to be emerging. I am worried, deeply, about means and process, not about ends and results. (2) The Nomcom process is good for many things, but has repeatedly and convincingly demonstrated that it is not effective in "curing" the IESG or IAB of particular forms of bad behavior. It has been especially ineffective at curing behavior consistent with the belief that the "leadership" is in control of the organization rather than a reflector, facilitator, and determiner of consensus. That is either a problem or not, depending on whether we care: it has often been observed that most organizations end up with the leadership they deserve, regardless of the selection mechanisms used to pick them. (3) We claim to not believe in voting or Ki
Re: [dnsop] Re: Root Anycast (fwd)
> Is there situation that multiple root servers installed behine > multiple routers within one AS? yes. that situation exists inside cogent, with c-root. > If router-P enables PPLB, would there be some problem with TCP based > DNS requests? your diagram didn't make sense to me so i'll answer without reference to "router-p". if cogent's backbone engineering staff enabled PPLB on the wrong set of output interfaces, all kinds of things would break, including tcp sessions to c-root. fortunately, their backbone engineers are smart enough to know how to use (or not use) the tools available to them. the rootops were pretty careful when we turned on anycast. presumably the other anycast services around the net, like woody's and rodney's, were also deployed very carefully. careful as in getting multiple experts in a room to argue out the fine points. careful as in monitoring the results and making sure there weren't any unreported (or reported) failures. anycast has worked very well. both inter-AS and intra-AS. the fact that a not-clueful-enough engineer *could* build a non-working topology using anycast and PPLB as ingredients, does not mean that anycast or PPLB are bad. it means you have to be clueful-enough before you use either tool. (and remember kids, all power tools can kill.) one hopes that an actual policy maker would find an actual expert for advice. such an expert would be expected to have read http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s21/pplb.htm where it says Restrictions Out-of-Sequence Packets Using per-packet load balancing to share the traffic load across available paths to a given destination can cause out-of-sequence packets in a particular data flow. This can result in unsatisfactory data transmission for video and voice streaming. and they would know that PPLB is basically a link bundling technology used when all members of the PPLB group start and end in the same router-pair; in other words it could mostly turn a pair of OC3c's into an "OC6" but it would be unsafe in any broader context, even when anycast is not in use. now, could y'all please stop feeding the trolls? ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Re: Question [Authorize]
Hi, You just sent an email to my Mailblocks spam-free email service. (If you didn’t recently send a message to me, please see the Note below*.) Because this is the first time you have sent to this email account, please confirm yourself so you'll be recognized when you send to me in the future. It's simple. To prove your message comes from a human and not a computer, go to: http://app4.mailblocks.com/confirm2.aspx?ck=DGphbWVzX21lc3Nlcg5tYWlsYmxvY2tzLmNvbQ1pZXRmQGlldGYub3JnZz-iNw**&a=1 This is the email message you have sent that is in my Pending folder waiting for your quick authentication: Subject: Re: Question Sent: Oct 2, 3:39 AM If you have not confirmed within several days, your message will automatically be deleted. *Note: If you did not send the above message to me, and you would like to report this email as unwanted, please notify Mailblocks by clicking here, and we will ensure that you do not receive any further notification regarding the above message. Mailblocks investigates all reports made using this link. - Email for Humans... Mailblocks Try Mailblocks web-based personal email -- faster, cleaner interface, more storage, bigger attachments, and 100% spam-free. About Mailblocks (c) 2003-2004 Mailblocks Inc. All rights reserved. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
CRAMing for last call
Now that bis is close to reality, I would like to push the final version of CRAM out as well. The two documents should be able to go through together, (I hope) making life easier for the RFC editor. I have some non-substantive editorial changes that will make the document a bit easier to read, but these are not show stoppers. I think all of the last round of comments are addressed in the current draft. If not, I would like to hear from people, soon. I would also like to solicit a few additional examples from anyone who has implemented CRAM in other than IMAP. Finally, we need to address the issue of the MD5 "break." I have held off from commenting on this issue until the community has seen explicit evidence of the attack, and the implications of it. At this point, I don't know if the document deserves a writeup on the attack. Theory abounds, but I haven't yet seen a practical attack that works in the general case. We should at the least make mention of what has been discussed, and point to the literature, but I don't think the document deserves to discuss all the possible attacks. This doesn't mean to discourage anyone from contributing text to the Security Considerations section (please do). The IMAP-EXT list has had recent discussion that points out the ambiguity of searching for the space (SP) separator (between the user id and the digest) as being the rightmost SP, so I will strengthen that text. Any other comments should come forth soon as I would like to run out the final draft at the end of next week (Oct. 8) if I can. Cheers, --lyndon (editor) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Complaint about inappropriate behavior by Stephane Bortzmeyer
The following message by Stephane Bortzmeye includes an inappropriate personal attack in violation of the following sections of the ISOC Code of Conduct: http://www.isoc.org/members/codeconduct.shtml 7 Only offer or claim to offer opinions or services that lie within the member's actual knowledge or competence. 8 In the case of financial or material conflict between personal and professional interests, or between two professional interests, declare this conflict to all interested parties and if appropriate in public. 9 Respect the generally accepted norms of Internet etiquette for human communications, especially by avoiding communications that are false or are likely to be considered as discourteous, objectionable, malicious, unwanted, or causing unjustified loss of prestige. Avoid fraudulent or deceptive statements. 11 Treat all users and colleagues fairly and on equal terms. And the message violates the following sections of the IETF Guidelines for Conduct RFC 3184: http://www.ietf.org/rfc/rfc3184.txt?number=3184 1. IETF participants extend respect and courtesy to their colleagues at all times. IETF participants come from diverse origins and backgrounds and are equipped with multiple capabilities and ideals. Regardless of these individual differences, participants treat their colleagues with respect as persons--especially when it is difficult to agree with them. Seeing from another's point of view is often revealing, even when it fails to be compelling. English is the de facto language of the IETF, but it is not the native language of many IETF participants. Native English speakers attempt to speak clearly and a bit slowly and to limit the use of slang in order to accommodate the needs of all listeners. 2. IETF participants develop and test ideas impartially, without finding fault with the colleague proposing the idea. We dispute ideas by using reasoned argument, rather than through intimidation or ad hominem attack. Or, said in a somewhat more IETF-like way: "Reduce the heat and increase the light" -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 -- Forwarded message -- Date: Sat, 2 Oct 2004 20:42:17 +0100 From: Stephane Bortzmeyer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [dnsop] Re: Root Anycast On Thu, Sep 30, 2004 at 08:48:37PM -0400, Dean Anderson <[EMAIL PROTECTED]> wrote a message of 56 lines which said: > If Av8 turns on PPLB, traffic to F-root will go through both sprint > and att on a per-packet basis. Troll Bot <[EMAIL PROTECTED]> keeps mentioning PPLB. May be some people more knowledgeable about BGP than I am will explain to me why PPLB is such a new issue for anycasting? Even without PPLB, the simple and normal (though infrequent) change of the routes by BGP may disturb existing TCP sessions if the target is anycasted. This is why anycast is currently deployed only on mostly-UDP services like the DNS. So, it seems there is nothing new coming from the PPLB thing. . dnsop resources:_ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Documenting the problems (Re: Level of consultation (Re: a note about the scenarios))
On 12:59 04/10/2004, Harald Tveit Alvestrand said:
--On 1. oktober 2004 13:48 +0200 "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]>
wrote:
I apologize for not having followed the debate over the IETF
administrative structure as I should have probable done it .
Dave's response seems to be the first I find interesting and
illuminating (may be I lost others).
Is there a draft/wiki documenting all the IETF problems?
Jefsey,
have you read RFC 3716 ("The IETF in the Large: Administration and
Execution") and RFC 3774 ("IETF Problem Statement")?
Dear Harald,
I apologize again about my Frenglish which lead to confusion. I had read
quickly these RFCs when published. I retained the feeling that one dealt
with the problems of interrelating with the existing IETF partners, and
that the other was about the internal IETF life problems. But none about
the real IETF problems. I then used the then image that one was about
outside wall painting and the other about inside wall papers, but none
about the walls themselves and about what they have been built for.
I reread them in detail. This is actually an impressive and honest work.
The current thinking I give on issues which impact the architectural usage
of the Internet helps me to see better how parts of this work may help. But
I have an increased feeling they help in no way the current debate, and
even make the discussion over different scenarii unreal.
To take back my image. I feel the discussion is : we identified that our
four contractors have some requests about the cleaning of the road, the
signs and the parking lot when coming to the house, how much they are paid
and how to best understand what we tell them. We identified that the kids
are not really happy with the wall paper, the overload of the parents, the
TV show in foreign languages and other family life issues. So let discuss
the tax relief in building a new house in stone or in wood, in McLean or in
Geneva, may address the problem.
I am sorry. When I talk about "IETF Problem" I see it from an IETF's user
point of view. This roughly means five things:
1. content, quality and usefulness of the deliverables (let first define
them and discuss the demand, this will tell where the money will come from)
2. surety, security, stability, adequacy, scalability, sovereignty respect
when using the IANA post-delivery services
3. currently missing deliverables (standardized code, missing functions,
digital convergence, multilingualism, maintained documents, test beds, etc.
etc.)
4. the interest for me to invest in using IETF deliverables. Will IETF foot
the real digital ecosystem needs? or stay with the 1983 TCP/IP model? For
how long? What is the contingency plan?
5. what about its competition? I observe usage architectures (P2P, used
interphone, spam, "Pluggable Edge Viruses", etc.. come from els where. IETF
does not foster competition. No alternative architecture worked on at
SourceForge - a long long fight against alt-roots, a monopoly oriented IPv6
design etc.. I accept there may are good reasons for that but I worry that
they have not been fairly and innovatively worked on.
This is why I considered Dave's mail as enlighting. I had the feeling he
was not that much talking about "photographed problems" but about real
users life problems.
But rereading this RFCs in this context, show the amountg of the work you
engaged. I want to thank you for that.
But I am afraid reorganizing the 2004 IETF to better carry its 1986 job and
redo the 1992 ISOC differently may not be the best target? The lack of
consensus about the IETF purpose in life has been identified as a key
problem. Should it not come before any possible rebuild?
And it is not just to say "write Internet documents". Some ideas about the
deliverables of these documents is needed. The debate may start with the
"core values" you quoted but is much, much more. At least IMHO.
Thank you for all.
jfc
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
Spencer Dawkins wrote: Erk! I haven't been involved with W3C since 2000, but I WAS involved in W3C during the late 1990s. It's worth pointing out that the "alternate routing" mechanism _did_ include a king - at that time, Tim was doing final endorsement for all "recommendations", and it looks like Director Endorsement is still the case (see http://www.w3.org/2004/02/Process-20040205/tr.html#q73). You know, Spencer. We *had* a king for a VERY long time, and it was Jon Postel as RFC Editor and IANA. And somehow we survived. While Jon was around somehow a vast plethora of standards got vetted, not the least of which were IP, TCP, UDP, ICMP, SMTP, FTP, SMTP, NNTP and DNS. I agreed with some of his decisions and disagreed with others. Probably the same would be true with Tim Berners Lee. But you missed my point. Don't like the IETF or the W3C? Try the TMF or the DMTF or the ITU or the GGF or the IEEE or roll your own (everyone else has ;-). I'm not saying don't make the IETF better. I think you do, by the way, through your participation (same with John Klensin and Dave Crocker, fwiw). I am saying that people have and will route around damage. Over this decision I doubt it will come to this. I have faith that the people in the IAB and the IESG care enough about the organization to listen to experts and make a good decision. I hope my faith is not misplaced. Regards, Eliot ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
And If the [Ll]eadership of this organization screws up badly enough, the Internet Community *WILL* route around the damage. It's happened before. That's how W3C came to be. Eliot Erk! I haven't been involved with W3C since 2000, but I WAS involved in W3C during the late 1990s. It's worth pointing out that the "alternate routing" mechanism _did_ include a king - at that time, Tim was doing final endorsement for all "recommendations", and it looks like Director Endorsement is still the case (see http://www.w3.org/2004/02/Process-20040205/tr.html#q73). We need to be careful what we wish for, sometimes... but thinking about John's note, and this factoid, is motivating me to finally read the drafts! Spencer ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Documenting the problems (Re: Level of consultation (Re: a note about the scenarios))
--On 1. oktober 2004 13:48 +0200 "JFC (Jefsey) Morfin" <[EMAIL PROTECTED]>
wrote:
I apologize for not having followed the debate over the IETF
administrative structure as I should have probable done it .
Dave's response seems to be the first I find interesting and
illuminating (may be I lost others).
Is there a draft/wiki documenting all the IETF problems?
Jefsey,
have you read RFC 3716 ("The IETF in the Large: Administration and
Execution") and RFC 3774 ("IETF Problem Statement")?
___
Ietf mailing list
[EMAIL PROTECTED]
https://www1.ietf.org/mailman/listinfo/ietf
Re: Reminder: Poll about restructuring options
Dear John, your last two mails do not point out all the problems (I am quite interested in Dave's remark on IANA), but they give a good account of a pure technical (management) problem. Internet is defined as the adherence of its users to the documents resulting from the Internet standard process. This process is well defined in theory but faces practical problems we can name an authoring quality, cost and pertinence loop. Let try to break the loop. We are in exactly the same situation as every publisher on earth: good texts cost. However unlike other publishers we do not pay authors and we do not pay media (for example we are proud RFC documents are free, while ITU documents are not). What every publisher on earth - and on the net - do when his revenues do not match the costs of his publication (readers do not pay, or do not pay enought)? Three possibilities : - either he pays (in our case : volontary work and contributions) - either advertizing pays the media - it means that sponsors think that pertinence will attract readers who will pay them back - or author pay the service - it means that the authors think quality is worth it Let consider publications like Nature or other professional publishers have advertzing pages. Then let think about the following ideas : - signing a draft (what makes publicity to the author and to the author's organization) should be charged in proportion to the author's organization possible commercial return. This is actually the case today, but not transparently and not oargnizaed so it is not efficient and even detrimental). Large organizations spend money ON the IETF (salaries, secretariat, translators). This actually slows the process because they do not suffer from its increased complexity and are not motivated to simplify it. Let now consider that the same total budget is spent BY the IETF: most of the problem would be gone because everyone could work in the same conditions for better deliverables. Let now consider that the money is provided by every Member (what we actually do since voluntaries pay with their own time - so they "pay" large organizations for the time their paid contributors can more easily spend): everyone would want to go faster. - this could translate easily in a basic (and polite) information provided when joining a WG - listed in the WG page. Who I am, what is my organization, what is the amount of time I can spend (salaries), what is the turn-over of my organization in datacoms. How much my organization can pay to sponsor this effort. Once this is published it would be very poor advertizing for an organization not to foot its pledge. But if they don't they could explain why ... transparently. Many things could be much clearer and benevolent dedication far more acknowledged and assisted. I suppose that internationalization could also be helped (non-US firms advertizing through their active support of the IETF standard process). - the interest would also be that before publicly showing interest and committing money (they already do it when they tell an employee to join a WG) organizations would most probably carry a market study. This would help WGs a lot. - obviously a mechanism should be found for "paying" subjects to sponsor more osbcure or research areas. Why nota "Nature-like" publications sponsoring IETF meetings. As a result I suppose IETF meetings receiving a better coverage could get more sponsoring. WGs would also probably get more "dormant" participants who would probably help at the end of the day in evangelizing or supporting testing. Such a system could be easily managed by an indepedent secretariat organization gathering the "sponsors" (actually authors and authors organizations). All of them being together would nullify the risks of one or few taking leadership. All the more if decisions (we are in administrative area only) are voted on a Member basis and not on a money contribution basis: contributing one dollar (euro, yen) once for one draft would give membership (while showing others if I am a serious contributor or a commercial fake). So it would be a resource management only organization by authors (large, small, individual and voluntaries) only. No impact on the essence of the content, but faster, better, more to the point content because a more efficient (fully respected better supported) Intenet standard process (cheaper to produce) or more demanded content by readers (users). Bill Manning testified that users were the problem: they are the IETF readers ... let us attract their interest, they will help one way or another - this is what one name commerce. jfc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Accusations of secrecy (Re: Reminder: Poll about restructuring options)
John, --On søndag, oktober 03, 2004 15:11:24 -0400 John C Klensin <[EMAIL PROTECTED]> wrote: The IAB and IESG continue to appoint secret (i.e., not announced and minuted) committees to hold secret (i.e., not announced in advance to the community) meetings, despite promises in San Diego that this would stop. I am sorry that you misunderstood what I said in San Diego. The IESG and IAB has had the substantive discussion of the restructuring right here on the IETF list. That's what we promised, that's what we delivered. The cards we have been dealt are on the table. It has also continued to have discussions among the IESG and IAB, as I believe is their right and duty, and to have discussions with the ISOC Board of Trustees, also in private, which I believe is their right and duty too. In the course of these discussions, some facts and arguments have come to light that I have not yet seen reflected on the list. Those, as far as they influence what the IESG and IAB proposes as solutions, need to be brought to the list. But I cannot accept the world picture that your accusatory sentence above seems to be painting. It's WRONG. Harald ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
