Re: delegating (portions of) ietf list disciplinary process
2. An IETF netiquette committee, to offload list banning procedures from the IESG. I don't think so. I prefer that this responsibility stay with a few individuals, so that it is taken very seriously -- not only by them but by everyone. A committee would lead to dilution of responsibility as well as endless discussion on every dispute. Good point. As much as I believe the IETF should not give veto authority to any single individual, this is one case where it is probably better. My sense is that, without exception, IETF participants involved in deciding process objections has taken their role extremely seriously. It's difficult to believe that this would be any different. In addition, any abuse by the ombudsperson will be very quickly reported and corrected. d/ -- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: delegating (portions of) ietf list disciplinary process
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 2. An IETF netiquette committee, to offload list banning procedures from the IESG. I don't think so. I prefer that this responsibility stay with a few individuals, so that it is taken very seriously -- not only by them but by everyone. A committee would lead to dilution of responsibility as well as endless discussion on every dispute. Good point. As much as I believe the IETF should not give veto authority to any single individual, this is one case where it is probably better. My sense is that, without exception, IETF participants involved in deciding process objections has taken their role extremely seriously. It's difficult to believe that this would be any different. In addition, any abuse by the ombudsperson will be very quickly reported and corrected. d/ -- Dave Crocker Dave- Of course it's a matter of opinion, so it's not like I'm trying to tell you I'm right and you're wrong, but think about every high court in the United states and many in Europe - none of them are 1 person but rather a group. There are reasons for this, most important of which is no one is right all the time - no one no matter how wisened sees every situation clearly from all angles - not to mention most everyone has their hot issues and areas of predjudice or misunderstanding. Having a group of seven or nine helps neutralize individual errors. I'd feel much safer being judged by tcp than udp. nick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Minority opinions [Re: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]]
JFC (Jefsey) Morfin wrote: At 19:17 27/09/2005, Brian E Carpenter wrote: ... My proposition would be to create a minority position system. Where such groups could be accepted as opposing without having to be fighting. There is a perfectly civilised way of handling minority opinions already. Please see RFC 3246 and RFC 3248 for an example I was personally involved in. 3246 is the consensus and 3248 is the minority opinion. Unfortunately not. RFC 3246 is Standard Track, RFC 3248 is informational. RFC 3246 is published. They are both published, and obviously the consensus document is the one on the standards track. It exactly an example of the IETF publishing a minority opinion. Obviously, we couldn't publish two standards for the same bits. This case is when two IETF groups have different opinions. The case I refer to is when an SSDO consensus opposes an IETF-WG consensus, That doesn't affect what the IETF publishes. The IETF publishes the documents that it reaches consensus on, after considering all contributions. Liaisons from other SDOs are considered. That doesn't mean we take them as instructions or have any obligations. When we become aware of another SDO working on an alternative solution, we normally attempt to engage in dialogue, but there is no algorithm for how that dialogue will terminate. while the Internet is no more a place where one can consider that an erroneous RFC supported by market leaders will quickly deprecate and not hurt. The resources of the other SSDO are dedicated to its own business. It may however make the effort of a QA delegate to the Internet standard process. Experience shows that without an MoU a conflict may quickly develop (as if two foot-ball teams met, but one team would, in addition to be a challenger, have only one player present. This is all the more true if the results of the match counts for the world cup). The minority position would avoid to enter into an SSDO/IETF complex MoU and liaison committee (I feel you are not found of anyway). All the more than the problem may be purely occasional and the solution be to politely pay attention to mutual needs rather than to ban the SSDO liaison. This can only be detrimental to a final common solution and would resolve nothing since the SSDO has human resources a plenty. If people from another SDO wish to submit a draft for publication as an RFC, I can't see any reason why the RFC 3248 approach won't work. I can't see any need to add more process than we already have. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
UN plans to take over our job!
http://www.theregister.co.uk/2005/09/28/wsis_geneva/ This is not their place to be deciding as if they ever owned the Internet. They have no rights to the Internet, by the very nature of it's structure. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UN plans to take over our job!
Will, don't believe everything you read on the Web. ISOC is heavily involved on our behalf in the WSIS meetings and despite all the noise I am hopeful that rational results will occur. Brian Will McAfee wrote: http://www.theregister.co.uk/2005/09/28/wsis_geneva/ This is not their place to be deciding as if they ever owned the Internet. They have no rights to the Internet, by the very nature of it's structure. ___ 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: [dnsop] [EMAIL PROTECTED]: Mismanagement of the DNSOP list]
On Thu, 29 Sep 2005, grenville armitage wrote: Since when have political conspiracy theories, Political conspiracy theory? The disparagement machine is working overtime. allusions to impending legal action I made no allusions. I demanded compliance with the law and performance of fiduciary duty, and for the IETF to stop defamation. That isn't an allusion. and references to other people's dating lives I made no reference to anyone else's dating life. However, memory serves that we dated the same girl. It is quite reasonable to question if the new partner of a lost romance is a target for long term vengeful behavior and animosity. Some people hold these grudges their entire lives. been admirable examples of 'forceful, stubborn, or persistent' discourse? These characteristics are all more admirable than court proven liar, professionally dishonest, or lack of personal integrity --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Correct middlebox behavior
On 9/28/05 6:50 PM, Fleischman, Eric [EMAIL PROTECTED] wrote: I believe that Keith's first paragraph below is widely accepted by the IETF. However, after re-reading RFC 3234, RFC 3303, and others I did not find any text within any RFC to explain our consensus opinion concerning correct middlebox behavior to be used to guide those outside of our community. Well, there is no IETF consensus on correct middlebox behavior. The behave working group is putting together documents that I think are probably pretty close to what you're asking for. RFC 3424 describes IAB concerns about some NAT workaround techniques but in that case the burden is on the workaround, not the middlebox. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: delegating (portions of) ietf list disciplinary process
On Thu, 29 Sep 2005, Nick Staff wrote: Of course it's a matter of opinion, so it's not like I'm trying to tell you I'm right and you're wrong, but think about every high court in the United states and many in Europe - none of them are 1 person but rather a group. There are reasons for this, most important of which is no one is right all the time - no one no matter how wisened sees every situation clearly from all angles - not to mention most everyone has their hot issues and areas of predjudice or misunderstanding. Having a group of seven or nine helps neutralize individual errors. I'd feel much safer being judged by tcp than udp. This is a good idea. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: delegating (portions of) ietf list disciplinary process (fwd)
Let me ask you Ken: Are you participating in the IETF as part of your job? Or are you just here for personal kicks? On Thu, 29 Sep 2005, Ken Raeburn wrote: Perhaps there is no legal standing for an expectation of privacy. It has nothing to do with legal standing. Its a question of etiquette. Office etiquette and backyard-fence etiquette are different. Still, it is generally considered discourteous among most serious email users, I think. But we seem to have gone past the point where that matters to people. This is only true with respect to PERSONAL communication. BUSINESS communication is not personal communication. If my friends tell me something personal outside of business, I keep it private, because its personal. My friends don't write personal notes to the IETF Chair complaining about me and my company. [certainly not feigning having no position.] That would be business, and they probably wouldn't be my friends anymore. If you file a motion with the FCC or write a nasty gram to the IETF Chair, its a business document. I have every right to publish it. Its not personal. And I do business favors, too, but I have no obligation to do so. You don't understand the distinction between business and personal. Actually, I'm now convinced that this is the whole problem with the abuse at the IETF: An inability to distinguish between personal and organizational interests and subject matter. So, if I wanted to make comments to you about IETF matters, people's personal conduct on mailing lists, etc, that I didn't want made public to fuel arguments I specifically don't want to add to, I should ask you to sign an NDA first? Got it, I'll keep that in mind. Those are business topics. If you are concerned about fueling something, then you should keep silent. Only a lack of fact adds fuel, otherwise known as hyperbole. You should consider your business commications differently from your personal communications. This has been vaguely entertaining for a while, at least until a friend of mine became one of the side targets. Oh, I sympathize. I thought it funny too, until I became a target of repeated abuse, defamation, and disparagement for merely making true statements that counterfeit anti-spammers didn't like. The good thing is, lies wash off. But the truth sticks with you forever. Once you are a Court-proven liar, associate with a court-proven liar, dishonest etc., that doesn't go away. Alan Brown will be a 3-time court proven liar for the rest of his life, unless he becomes a 4-time court proven liar. Nothing he does will ever remove that. Even a lesser miscreant, Chris Neill, fired for conducting open relay abuse he was convinced was undetectable in 1999, just recently sent me a nasty gram. 6 years later, and he hasn't forgotten. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Fwd: UN plans to take over our job!
-- Forwarded message --From: Will McAfee [EMAIL PROTECTED]Date: Sep 29, 2005 10:22 AM Subject: Re: UN plans to take over our job!To: Doo Timbir [EMAIL PROTECTED]Looking back, I guess I was talking like an idiot. I apologize, for this, was just outraged at this treatment of the Internet as something they owned. And also The Register is no tabloid. =/ On 9/29/05, Doo Timbir [EMAIL PROTECTED] wrote: I personally think that it is too late for any group to lay hold of the Internet. The right thing to do is to allow it to be[exist] the way it is period! Sincerely, Doo Timbir.Will McAfee [EMAIL PROTECTED] wrote: http://www.theregister.co.uk/2005/09/28/wsis_geneva/ This is not their place to be deciding as if they ever owned the Internet. They have no rights to the Internet, by the very nature of it's structure.___Ietf mailing list Ietf@ietf.orghttps://www1.ietf.org/mailman/listinfo/ietf Yahoo! Messenger NEW - crystal clear PC to PC calling worldwide with voicemail ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the normative nature of IETF RFCs
JFC (Jefsey) Morfin wrote: Interestingly, Transpac, the French X.25/Minitel network (by then the largest data network in the world, so acting as a kind of reference) published a test machine (probably around 1982?) everyone could use to verify his conformance to the (stringent) network requirments. At the Den Hague ISIS Club (1984?) the Dutch PTTs proposed to extend that pratice to the whole International Network, standardising the running test program concept (for OSI, DECNET, IBM/SNA, Swift, Sita, etc.. then supported protocols). . This was further discussed within the CEPT (European Public Operators Club) for OSI services, but I did not heard of any decision or CCITT (ITU-T) proposition. This kind of standardisation by the running test was a standard question when discussing a new root name interconect. But I do not think it was used by any other OSI operators ? The concept is however appealing: to add a test running code to an RFC, as a way to document, check and enforce its standard? My experience with this sort of thing was pretty negative. I worked on an X.25 DTE implementation in the early 1980s, and we had to get it certified by a US government agency in order to be allowed on one of the government networks. The certification code appeared to have had been written by a junior engineer, and it required behaviour that was inconsistent with the written standards and would have caused significant interoperability problems. So we did what everyone else did: we submitted hacked code for the certification test, got the certification paper, and then deployed our original code (which was compliant with the standard and was known to interoperate with the equipment we had to talk to). My hazy recollection of the Transpac certification tests is that their test machine actually did a relatively good job, but that they did not require certification to connect to their network. IIRC they didn't believe that non-conforming behaviour from a DTE would harm the network ... if it failed to interoperate, it the customer/vendor would be motivated to fix it. //cmh ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Minority opinions [Re: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]]
At 13:32 29/09/2005, Brian E Carpenter wrote: They are both published, and obviously the consensus document is the one on the standards track. It exactly an example of the IETF publishing a minority opinion. Obviously, we couldn't publish two standards for the same bits. Dear Brian, this is why we need to find ways to help consensual standard publication first. The problem is worst if the document claims to be a BCP. This case is when two IETF groups have different opinions. The case I refer to is when an SSDO consensus opposes an IETF-WG consensus, That doesn't affect what the IETF publishes. The IETF publishes the documents that it reaches consensus on, after considering all contributions. Liaisons from other SDOs are considered. That doesn't mean we take them as instructions or have any obligations. We should not be here to develop non-interoperability. However we know that competition may lead to some oddities. This is the theme of RFC 3869. When we become aware of another SDO working on an alternative solution, we normally attempt to engage in dialogue, but there is no algorithm for how that dialogue will terminate. normally should be replaced by SHOULD. All what I call for is not even to engage in a dialog, but to respect others and not refuse the dialog. And a way to politely but clearly address the possible non-technical motivations. I think an Ombudsman can help that. And that the minority position is the way to inform that he has been informed and taken the issue seriously. The impact is only to make the things even. Disfavors no one, helps everyone. If people from another SDO wish to submit a draft for publication as an RFC, I can't see any reason why the RFC 3248 approach won't work. I can't see any need to add more process than we already have. The RFC 3248 approach is internal to IETF. Other SSDOs have their own charters and agenda. We are talking of interoperability. When IETF disregards others, it is lucky others pay attention and delegate a resource they need. Forcing others to become more competent in a whole IETF area they are not interested in to publish a document so the better win, just to prevent a lobby from creating a profitable interoperability conflict with other commercial or non-profit/publicly funded SSDO, is not the way I see global networking. Please consider RFC 3869. I may be wrong though. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Question about the normative nature of IETF RFCs
On Wed, 2005-09-28 at 16:50, Fleischman, Eric wrote: That RFC said hosts do X and other devices (which in that era meant routers) do Y. They do Y because they are not hosts -- middleboxes are sometimes router-like, and sometimes host-like, and sometimes both at the same time, and sometimes neither. And this is just another instance whereby the specs are always incomplete -- something new comes along which is neither host nor router. and, in such cases, implementors need to use their brains about which behavior makes most sense given the context rather than interpreting the words in the spec as if they were code. rather than correctly behaving as middleboxes are supposed to do. except that I don't believe there's a single type of middlebox ... - Bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Question about the normative nature of IETF RFCs
On 9/29/05 1:24 PM, Bill Sommerfeld [EMAIL PROTECTED] wrote: except that I don't believe there's a single type of middlebox ... There certainly isn't. RFC 3234 created a middlebox taxonomy based on what we knew at the time, and I think it's held up pretty well over the past three years. People worried about middleboxes should probably give it a read. Melinda ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Minority opinions [Re: [EMAIL PROTECTED]: Mismanagement of the DNSOP list]]
At 13:32 29/09/2005, Brian E Carpenter wrote: They are both published, and obviously the consensus document is the one on the standards track. It exactly an example of the IETF publishing a minority opinion. Obviously, we couldn't publish two standards for the same bits. Dear Brian, this is why we need to find ways to help consensual standard publication first. The problem is worst if the document claims to be a BCP. This case is when two IETF groups have different opinions. The case I refer to is when an SSDO consensus opposes an IETF-WG consensus, That doesn't affect what the IETF publishes. The IETF publishes the documents that it reaches consensus on, after considering all contributions. Liaisons from other SDOs are considered. That doesn't mean we take them as instructions or have any obligations. We should not be here to develop non-interoperability. However we know that competition may lead to some oddities. This is the theme of RFC 3869. So you said: 1) we shouldn't develop anything that disagrees with anything else (implying external consensus as well as internal consensus). -AND- 2) we should support spreading minority opinions, and the minority opinion should be of the same status as the main opinion. That position is untenable. First you complained about the lack of minority opinion, then the difference in status, then the fact that everyone didn't just hang around waiting for everyone to agree. Perhaps instead of repeated disagreement with people's positions, you should offer a clear concise vision of your own. As far as finding a consensual standard, in anything I believe an open mike in coordination with rough consensus and running code will always be the best answer. When we become aware of another SDO working on an alternative solution, we normally attempt to engage in dialogue, but there is no algorithm for how that dialogue will terminate. normally should be replaced by SHOULD. Why? So people who disagree internally can form an external body to essentially propigate a DOS situation on our progress? So instead of focusing on the technical issue at hand we can have engineers and scientists (mostly) concerned with politics and diplomacy? I do not agree at all. All what I call for is not even to engage in a dialog, but to respect others and not refuse the dialog. And a way to politely but clearly address the possible non-technical motivations. I think an Ombudsman can help that. And that the minority position is the way to inform that he has been informed and taken the issue seriously. The impact is only to make the things even. Disfavors no one, helps everyone. Who is not permitted to make their voice heard on an IETF list? Are you saying non-technical matters should in any way trump technical issues? I don't believe that idea will find much of a home in this forum. If people from another SDO wish to submit a draft for publication as an RFC, I can't see any reason why the RFC 3248 approach won't work. I can't see any need to add more process than we already have. The RFC 3248 approach is internal to IETF. Other SSDOs have their own charters and agenda. We are talking of interoperability. When IETF disregards others, it is lucky others pay attention and delegate a resource they need. Forcing others to become more competent in a whole IETF area they are not interested in to publish a document so the better win, just to prevent a lobby from creating a profitable interoperability conflict with other commercial or non-profit/publicly funded SSDO, is not the way I see global networking. Please consider RFC 3869. I may be wrong though. I don't know about wrong, but seemingly political. It seems you've managed to find fault in many other's statements (sometimes to the point of contradicting your own), and succeded in prognosticating doomsday scenarios all without suggesting a proactive response or outcome in anyway. -Tom smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UN plans to take over our job!
Will McAfee writes: http://www.theregister.co.uk/2005/09/28/wsis_geneva/ This is not their place to be deciding as if they ever owned the Internet. They have no rights to the Internet, by the very nature of it's structure. Placing governments in charge of the Internet would be a disaster, the worst possible thing that could happen to it. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Correct middlebox behavior
This doesn't cover all of what middleboxes do, but the part about them faking responses (e.g., to splice connections), hijacking, or NATing are covered in RFC1122 sec 3.2.1.3: When a host sends any datagram, the IP source address MUST be one of its own IP addresses (but not a broadcast or multicast address). I don't see anything in 1812 that prohibits routers from modifying the contents of an IP datagram, but the term 'forwarding' never permits modification of the IP payload either. Joe Fleischman, Eric wrote: Friends, I believe that Keith's first paragraph below is widely accepted by the IETF. However, after re-reading RFC 3234, RFC 3303, and others I did not find any text within any RFC to explain our consensus opinion concerning correct middlebox behavior to be used to guide those outside of our community. Specifically, can anyone point me to text within any RFC that states the ideas contained within Keith's first paragraph below? --Eric -Original Message- From: Keith Moore [mailto:[EMAIL PROTECTED] Subject: Re: Question about the normative nature of IETF RFCs Most protocols weren't designed to operate with middleboxes. In the absence of a provision in a protocol specification for a middlebox, any middlebox that interferes with the interoperation of a protocol is inherently violating the protocol standards. In general, protocol specifications don't (and shouldn't) try to explicitly enumerate don't do X for every possible X that is harmful. And middleboxes are generally harmful. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UN plans to take over our job!
On Thu, 29 Sep 2005, Anthony G. Atkielski wrote: Will McAfee writes: http://www.theregister.co.uk/2005/09/28/wsis_geneva/ This is not their place to be deciding as if they ever owned the Internet. They have no rights to the Internet, by the very nature of it's structure. Placing governments in charge of the Internet would be a disaster, the worst possible thing that could happen to it. I'm the king, and you're nothing! That's right, you're the king of nothing. With appologies to Alice and Ralph joelja ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: delegating (portions of) ietf list disciplinary process (fwd)
On Sep 29, 2005, at 9:39, Dean Anderson wrote: Let me ask you Ken: Are you participating in the IETF as part of your job? Or are you just here for personal kicks? It's part of my job; has been for a few years. It has nothing to do with legal standing. Its a question of etiquette. Office etiquette and backyard-fence etiquette are different. True. Still, it is generally considered discourteous among most serious email users, I think. But we seem to have gone past the point where that matters to people. This is only true with respect to PERSONAL communication. BUSINESS communication is not personal communication. Business communication is not one homogeneous class of communications. Technical matters on the IETF lists are one thing; personnel discussions about employees would be quite another. And the level of privacy expected, and the degree of rudeness associated with publishing someone's not-previously-public communications, vary; they are not binary choices. Email I might exchange with selected individuals outside MIT on how to implement some feature in our (open source, repository-accessible) product would fall somewhere in between. In my experience there is certainly work-related email that is not legally required to be private but would be considered rude to disseminate widely without getting permission. In this particular case, where it sounds like the mailing list was explicitly kept off the recipient list, that sounds like a pretty clear indication that the sender probably didn't want it as public as the previous mail being responded to -- much as if someone took you aside from a crowd to make a couple of comments instead of shouting at you in the middle of the room. Perhaps you don't distinguish those cases; other people do. But apparently your interpretation of business etiquette trumps his wishes, and whatever his intent was in not including the IETF at large ... in your mind, though apparently not his, and not mine. You don't understand the distinction between business and personal. I understand that the type of a communication cannot be fully represented in one binary digit. Actually, I'm now convinced that this is the whole problem with the abuse at the IETF: An inability to distinguish between personal and organizational interests and subject matter. There may be some of that. I strongly doubt that's all there is to it, though. So, if I wanted to make comments to you about IETF matters, people's personal conduct on mailing lists, etc, that I didn't want made public to fuel arguments I specifically don't want to add to, I should ask you to sign an NDA first? Got it, I'll keep that in mind. Those are business topics. If you are concerned about fueling something, then you should keep silent. Only a lack of fact adds fuel, otherwise known as hyperbole. Sometimes what's needed is to encourage both sides to step back a bit from a dispute for a while, or suggest that one side use or abandon some specific line of argument to make the discussion more productive. I think that's sometimes better done in private communication with individual parties rather than in public, but it's still business, and one shouldn't need an NDA to figure out that it's preferably not to be made public. (Then again, I guess sometimes making it public -- look! even so-and-so thinks you're a loser! clearly I'm right! -- may suit one person's desire to fan the flames, or to win at all costs. It may be jumping to conclusions to think that *everyone* wants a polite, productive discussion, or that they're capable of engaging in one in the face of strong opposition) I'm sad to say, I've actually looked at a little of the stuff you've posted on the web page you set up recently, concerning Ted Ts'o. I picked the July 1 off-list stuff to look at, briefly. From that admittedly small sample... let me try to phrase this carefully to avoid anything that might be construed as an ad-hominem attack: I disagree with your summary of some of the messages I reviewed. Ted disagrees with you on the importance of some things you bring up, and says what you're presenting isn't very useful (to the discussion at hand, I would assume he meant, on reading his message); your summary turns this into ``Tso says facts are not useful to the IETF.'' Without a qualifier like these facts and this discussion, that's an unsupported, even absurd, generalization; you're ascribing to Ted statements that he did not make. Ted asked for information on the court-proven liars (plural, your phrase), and you seem to have responded with info on multiple court cases against one person. Ted points that out, and uses the somewhat inaccurate description lost a lawsuit in doing so. He does acknowledge that this *one* person is, in at least one instance, a court-proven liar as you put it; his
Re: delegating (portions of) ietf list disciplinary process (fwd)
--On torsdag, september 29, 2005 17:02:48 -0400 Ken Raeburn [EMAIL PROTECTED] wrote: So, to summarize my look at a few of the messages: You both lose points for some of your statements or how you tried to make your arguments, and the accuracy of the summary page is questionable. None of it, so far, really suggests any sort of professional dishonesty on Ted's part to me. (If this were a research paper instead of an email message, I'd probably want him to be much more careful and even pedantic in his arguments, but that would be about the quality of the work, not honesty.) I think you illustrate quite well why I'm glad I don't have to talk to Dean Anderson any more. Any conversation where I can't toss of a casual remark without getting virtually crucified for it is a conversation not worth having. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UN
I don't want to clutter up everyone's inboxes with dozens of rants that amount to hyperventilating and lots of Iiii's!, but if anyone would like to e-mail me off list with their thoughts on the UN's WSIS conference and why having them replace ICANN would be a good/bad thing for the Internet, I would love to hear it. I'm not looking to pick a fight or argue - I'm just honestly interested in hearing the various opinions. The issue is a lot bigger than anything I can get my head around right now, and hearing what other people have to say would help me think about it more constructively. I myself am on this list more or less Just for kicks, or, as I prefer to think of it, personal edification, but do note that it is possible quotes from your e-mails will make it onto a personal site that I use for my own rambling and probably incoherent research. If you don't want this, just say so. -Alexis PS: Bonus points if you actually read what they are proposing before you respond. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: delegating (portions of) ietf list disciplinary process (fwd)
Geez, Harald. You misspelled off. Am I going to have to virtually crucify you in front of the list for this? -Alexis On Thu, 29 Sep 2005, Harald Tveit Alvestrand wrote: ::I think you illustrate quite well why I'm glad I don't have to talk to Dean ::Anderson any more. :: ::Any conversation where I can't toss of a casual remark without getting ::virtually crucified for it is a conversation not worth having. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UN
Alexis Turner wrote: I don't want to clutter up everyone's inboxes with dozens of rants that amount to hyperventilating and lots of Iiii's!, but if anyone would like to e-mail me off list with their thoughts on the UN's WSIS conference and why having them replace ICANN would be a good/bad thing for the Internet, I would love to hear it. I'm not looking to pick a fight or argue - I'm just honestly interested in hearing the various opinions. The issue is a lot bigger than anything I can get my head around right now, and hearing what other people have to say would help me think about it more constructively. I myself am on this list more or less Just for kicks, or, as I prefer to think of it, personal edification, but do note that it is possible quotes from your e-mails will make it onto a personal site that I use for my own rambling and probably incoherent research. If you don't want this, just say so. -Alexis PS: Bonus points if you actually read what they are proposing before you respond. Hi Alexis, I followed the discussion list. I could hardly follow it. Is there a UN? To me it looks like a bunch of small and not so small dictators at the table and several rooms full of intelligent people outside. It might be interesting to give them the internet. But how should you do that? What could they do with it? Give them the root. The root operators will laughingly stand up and go away. Each of them will start running his own root on his own hardware. The internet hardware? Belongs to companies that were not allowed to join. How should all the internet operators find out what the UN want them to do if they dont allow them in? I dont think anything but a lot of wasted paper will come out of that meeting. Kind regards, Peter and Karin Dambier -- Peter and Karin Dambier Public-Root Graeffstrasse 14 D-64646 Heppenheim +49-6252-671788 (Telekom) +49-179-108-3978 (O2 Genion) +49-6252-750308 (VoIP: sipgate.de) +1-360-448-1275 (VoIP: freeworldialup.com) mail: [EMAIL PROTECTED] http://iason.site.voila.fr http://www.kokoom.com/iason ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UN
At 1:41 AM +0200 9/30/05, Peter Dambier wrote: Give them the root. The root operators will laughingly stand up and go away. Each of them will start running his own root on his own hardware. You talk as if you were a root operator and you know what they would do. In fact, you run an alternate root, not a real root, so it seems that you knowing what real root operators would do is particularly unlikely. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: delegating (portions of) ietf list disciplinary process
From: Theodore Ts'o [mailto:[EMAIL PROTECTED] Ted- Sorry for taking so long to respond - I wanted to give some thought to your questions before replying (comments in-line) On Tue, Sep 27, 2005 at 06:47:36PM -0700, Nick Staff wrote: 2. An IETF netiquette committee, to offload list banning procedures from the IESG. I'm a big fan of the netiquette committee. I'd like to suggest that volunteers be allowed to throw their names into the hat and that members be selected blindly from that pool. This would of course avoid any stacking or favoritism, but we would need a qualifier that prevented interlopers from submitting their name. Though I hate to suggest it as it would exclude me from selection, having attended an IETF meeting in the last x years could possibly be a good filter. Maybe. I see two potential problems: 1) Serving on this committee is going to be no fun at all. Getting qualified people to sign up for what will only be seen as a sh*t job is going to be difficult. I figure if Brian was able to get multiple volunteers for the IESG scribe position (of which I was one), then this should be a cakewalk ;) And how do you exclude certain known (repeat) troublemakers from throwing their hat into the ring? Or maybe you don't, but then if they get selected, they would then have the opportunity to practice their own unique form of DOS on the netiquette committee? Here are some general design points I've been thinking about to help prevent the DOS you speak of as well as some other pitfalls: 1. 7 or 9 member committee 2. Members selected blindly from pool of volunteers *Let's not forget that no matter who you are, there is someone out there who thinks you're a troublemaker, that you're dumb, mean, etc. This is why it's open to all volunteers, to prevent the tainting of the committee and the stacking towards one point of view.* 3. Majority can close discussion and force vote 3a. Unanimous minority can stay vote for max of 2 days 4. Verdicts are made up of 2 separate votes 4a. In the first vote, the committee members vote whether to sustain or refute the petitioners claim. 4b. In the second vote (which immediately follows the first) the members vote on the punishment. One of the choices MUST always be to issue a warning. The other choices will vary depending on the petition. 4bb. Anyone who is issued 3 warnings in less that a years time, on subsequent punishment votes there MUST NOT be the choice to issue a warning. This will be for a period of 1 year beginning on the day their third warning was issued. 4c. Note that when a petition is sustained the committee votes on a PUNISHMENT FOR THE ACCUSED, and when a petition is refuted the committee votes on a PUNISHMENT FOR THE ACCUSER. This should help curtail frivolity. 5. Any sentence suspending someone's posting rights due to abusive/off-topic posts is required to pass with no greater than 1 dissenter. This is to enforce the idea that if there can be sensible disagreement about whether a post's off-topic, then it's too subjective for such a serious punishment. 5a. When 2 voting choices differ only on length of time, then their votes may be added together to reach the needed majority - however in those cases the shorter of the two sentences MUST be imposed. For example if 6 members vote for a 1 year ban and 2 vote for 30 days (with 1 voting for a warning) then even though there is not sufficient majority for a ban, the six votes and the two votes can be added together which means the ban will pass - however it can only be a 30 day ban and can never be the greater of the two. 6. In all cases the dissenting minority is allowed to publish their dissention along-side the majority verdict (in fact, one MUST NOT ever be stored, displayed, or considered without the other. 2) Unless discussion of the decisions of the netiquette committee, during the committee is considering a request, and after the committee has rendered a decision, is ruled out of scope, it's not going to help the very long discussions such as this one which plague the IETF list. In the worst case, we can assume that the mailing list abuser will immediately appeal any decision of the netiquette committee, which means that after inventing this entire mechanism, it may not have any effect other than prolonging the agony. I know personally, if I feel a process is fair, then even if I hate the decision I can accept it and move on. That's another reason why I think it should be an unmanipulated membership. I also think the dissenting opinion will help here. Sometimes just hearing someone agree with you is enough to calm the whole situation down and give someone a sense of justice or understanding - even if the majority verdict is against them. thanks, Nick ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: delegating (portions of) ietf list disciplinary process
I, for one, welcome our new, everyone must be heard multiple times and feel good-bearing overlords. Oh. This isn't a slashdot discussion? My bad. gja (feeling grumpy) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Summary of the LLMNR Last Call
On Sep 20, 2005, at 10:55, Bernard Aboba wrote: DNSsec is very important for other reasons, such as the current pharming attacks. The risks have been known in the security community since at least 1991, and publicly since at least 1995. The long- predicted attacks are now happening. We really need to get DNSsec deployed, independent of mDNS or LLMNR. Given that there is now some forward progress on DNSsec, it's not at all unreasonable for either or both of those specs to rely on it to solve some of their particular security risks. Couldn't agree more. But if I'm not mistaken, the current DNSSEC specifications do not mandate that DNS stub resolvers be DNSSEC-aware validating, which is what would be required for use in a peer-to-peer name resolution protocol. There is also the DNSEXT WG edict that mDNS/LLMNR not share a cache with DNS, which makes it difficult for mDNS/LLMNR to utilize trust anchors or acquired keys present in the DNS cache. not to distract too much from the LC issues but there is an ongoing effort to define ways to have a standard API for validation by applications. Part of that work is understand what the term cache means in this context. And does validation have to work in lockstep w/ resolution? Regardless, a common API is highly valuable. there have been a couple of meetings on these issues already and we would be glad to have more inputs. --bill ___ 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: UN
Paul Hoffman writes: You talk as if you were a root operator and you know what they would do. In fact, you run an alternate root, not a real root, so it seems that you knowing what real root operators would do is particularly unlikely. There really isn't any such thing as a real root or alternate root on the Internet, just as paper currency and coins have no real value. It all depends on what the majority decides to do. If everyone switches to an alternate root tomorrow, then the real root won't matter. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UN plans to take over our job!
Will McAfee writes: http://www.theregister.co.uk/2005/09/28/wsis_geneva/ This is not their place to be deciding as if they ever owned the Internet. They have no rights to the Internet, by the very nature of it's structure. Placing governments in charge of the Internet would be a disaster, the worst possible thing that could happen to it. a peer 2 peer replacement for DNS tops my internet wish list; with such, we would not need the top organizations we have today, it would be much harder for anyone to claim the net and thus we wouldn't be having this discussion. of course, a p2p net of that size is a challenge but it's that kind of thing that make engineering fun :) - Johan Henriksson ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: UN
On Fri, Sep 30, 2005 at 05:40:24AM +0200, Anthony G. Atkielski wrote: Paul Hoffman writes: You talk as if you were a root operator and you know what they would do. In fact, you run an alternate root, not a real root, so it seems that you knowing what real root operators would do is particularly unlikely. There really isn't any such thing as a real root or alternate root on the Internet, just as paper currency and coins have no real value. It all depends on what the majority decides to do. If everyone switches to an alternate root tomorrow, then the real root won't matter. That's sounds good, but in fact, it's utter nonsense. It's like saying that the only difference between rowboat and a cargo ship is what people believe about them. In fact, if everybody started using one of the alternate roots, it would simply collapse. There is far more to the real root system than just human sentiment. There is heavy duty infrastructure, both human and physical, involved. -- Kent Crispin [EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649 [EMAIL PROTECTED] SIP: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RFC 4211 on the Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF)
A new Request for Comments is now available in online RFC libraries. RFC 4211 Title: Internet X.509 Public Key Infrastructure Certificate Request Message Format (CRMF) Author(s): J. Schaad Status: Standards Track Date: September 2005 Mailbox:[EMAIL PROTECTED] Pages: 40 Characters: 86136 Obsoletes: 2511 I-D Tag:draft-ietf-pkix-rfc2511bis-08.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc4211.txt This document describes the Certificate Request Message Format (CRMF) syntax and semantics. This syntax is used to convey a request for a certificate to a Certification Authority (CA), possibly via a Registration Authority (RA), for the purposes of X.509 certificate production. The request will typically include a public key and the associated registration information. This document does not define a certificate request protocol. This document is a product of the Public-Key Infrastructure (X.509) Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc4211.txt ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
