Re: discouraged by .docx was Re: Plagued by PPTX again
On Nov 28, 2011, at 12:27 PM, Julian Reschke wrote: It requires a format that does allow reflowing and repagination. HTML does, PDF/A does, text/plain does not (maybe RFC 2646 would help, maybe not). text/plain is what we use, and that's a problem that'll need to be solved. In practice, reflowing RFC-formatted text/plain works just fine. You have to skip the page headers, but it's really not that bad. Yes, ASCII-art won't work well --- but a 800x600 SVG jpeg won't work well on a 3 screen anyway. -- Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Plagued by PPTX again
On Nov 18, 2011, at 2:03 AM, John Levine wrote: * - You don't want to get locked into open source, credited to an IBM salesman Because once you try an open source mail reader, you'll never want to go back to Lotus Notes? :-) -- Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
On Sep 7, 2010, at 10:30 PM, Richard Bennett wrote: I'm making a very simple request, Brian: I want a new press release to go out that corrects the one that most assuredly did go out last week. There are many things I'd want, starting with a $10 million dollars in my bank account. I think we've all heard want you want. The fact that you want something doesn't mean that you (or I) should automatically get it. I find myself in agreement with Russ and Brian; I think his statements are fine on the face of it. I find ATT's statements that paid prioritization of Internet traffic... is already a common practice of Web management to be very misleading (certainly not on the wired internet, and it's not done at the Web layer), and that prefixes their claim, ... and consistent with protocols set with the IETF. I, personally, don't think we need to do anything beyond what Russ has already done, and I support his actions. -- Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: My comments to the press about RFC 2474
On Sep 8, 2010, at 7:07 AM, Richard Bennett wrote: You can read ATT's letter to the FCC here: http://fjallfoss.fcc.gov/ecfs/document/view?id=7020910396 OK, I find the section heading, Paid Prioritization Expressly Contemplated by the IETF to be highly misleading. I think you'll find that the phrases you quote below are not in the letter, so it's not clear that your comments are in any way relevant to the issue under discussion, Ted. We don't know what ATT said to the reporter, do we? And what we seem to be arguing about is a press release, not a formal submission to the FCC stating an official position of the IETF (something which the IETF generally doesn't do). In any case, I still don't think we need to do anything, and if it's OK for you to state wants, I'll state a want. I want you to drop this. :-) -- Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On Apr 2, 2010, at 6:46 PM, Hadriel Kaplan wrote: Not to belabor this thread, but... I was in Schiphol the week before IETF Anaheim and bought a train ticket. *None* of the my cards worked (Amex, Visa, Mastercard, and a debit, and yes I tried all of them). In fact, not only did they not work at the machines, but they were not accepted at the human-based ticket counter either, despite my having a Passport and one of the cards even has my picture on it. They had a sign even warning that it wouldn't work without a PIN. It was cash only, but there is an ATM near by. I travel a lot and was quite surprised. This was my experience as well (I travel a lot, to many countries in Europe and Asia, and have never had a problem until I travelled to the Netherlands last year) --- except my ATM card didn't work, either. When I talked to my bank, they told me it was because of fraud problems in that country specifically; I would have needed to warn them at least a few days in advance i was planning on visiting the Netherlands for them to put my card on a special authorization list. Maybe all of my credit card providers (Amex, Chase, Citigroup, etc.) are losers (actually, the problem with Amex was that the train station didn't accept it, not that my Amex card didn't work. Ultimately Amex was the only card that worked for me, and I ended up getting a cash advance using my Amex card), but if I were you, I'd bring Euros, and make sure you inform your bank and credit card issuers in advance. I've never needed to do this before when traveling to other countries, and I've never had trouble getting local currency out of an ATM machine, so I had gotten complacent -- Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
I'd recommend telling your bank and your credit card issuers that you are planning on traveling to The Netherlands at least a week or two in advance. My ATM card and two of my credit cards had a policy last year of declining all charges from that country due to large amounts of ATM/credit card fraud several years ago. Of course, I only found that out after the conference closed and I had absolutely no way of purchasing a train ticket back to Amsterdam I ended having to walk for a mile or two to find a post office to change US Dollars to Euros, since the only credit card that I had that worked in The Netherlands was my American Express card, and (a) I didn't know its pin number, and (b) it was accepted at the train station. (And when I called my bank to get my ATM card authorized for The Netherlands, they told me it would take 24-36 hours, and I wasn't going to be in the country that long. Very Frustrating.) My fault for not having a secondary backup of traveling with a hundred dollars of Euro bills, of course, which is now my standard policy. I had gotten spoiled with having my ATM card work everywhere.. -- Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meetingof the IETF
On Mon, Oct 12, 2009 at 09:44:58AM -0700, Dave CROCKER wrote: The questions constitute a denial of service attack on IETF operations. In terms of principle, I and others have pointed out the basic flaw in asking these types of question. The mere fact of having some questions does not justify asking them and most certainly does not justify requiring that they be answered. In terms of pragmatics, you are missing the fact that there is an infinite number of questions that one can ask and that it is not feasible to answer them, nevermind require that they be answered. Historically, the general culture of the IETF is that if people have a good question, it's always in scope to raise it. After all, as an engineering organization, our goal is protocols that _work_, and not just following Policies and Procedures. In fact, I'd like to think that part of the IETF culture which makes things different with say, ISO. With ISO, even if the protocol is fatally flawed, if it's in wrong part of the process, they'll go ahead and approve the standard just because the right number of national bodies had voted on it. With the IETF, even at last call, if someone can raise a valid technical objection that hasn't been previously considered, the IESG is supposed to consider that objection. If they don't, that can be a valid matter to appeal. So it seems kind of out of the IETF culture to say, this question is shouldn't be answered because it didn't come from the wrong part of the structure. That's like saying that a Management AD can't raise a question about security because they aren't from the Security Area. It's not considered a denial of service attack. It's considered a valid issue that should be considered. Ultimately, of course, there are checks and balances to make sure it's not a question that has already been asked and answered, and whether or not the question is valid or not. But we generally don't say, la la la la la --- it's not even right to ask the question because you're not from the right area. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sat, Oct 10, 2009 at 04:56:43PM -0700, Ole Jacobsen wrote: Since I am also not a US citizen, let me ask you a related question. Objectionable hotel clauses notwithstanding, some folks have argued that we should basically boycott China and not hold a meeting there for reasons ranging from Internet policies to Human Rights. Given the large and increasing number of Chinese engineers that participate in the IETF, what sort of message would we be sending by taking that kind of position? I really don't think boycott is the right word --- or at least, it's not conducive to discussion. That word is loaded with a lot of connotations, both good and bad. It implies that we hope to change China's behavior and/or legal system by refusing to attend a meeting in that country until they make changes that we feel Should Happen --- and while there may have been one or two people who have said things that might lead people to believe that, I at least am under no illusions that China is likely to change its behavior based on any demands made by the IETF. So Boycott could be seen by some as a word used by those who are trying to argue that we should have a meeting in China no matter what. Perhaps a better way of putting things is that the IETF has various requirements for holding a successful meeting, and the question is how much of a guarantee we need that we can have a successful meeting, and hold certain conversations without being in fear of the meeting getting shut down and/or IETF attendees getting imprisoned? The fact that China is the world's biggest jailer of cyber dissidents ought to give one pause; the counter argument seems to be that China it's really not about the law, it's about who you know, and that people in China care enough about the honor of having an IETF that they're not likely to imprison something even though there are scary words in the hotel contract and in Chinese National Laws. This is despite the fact that the grounds upon which Chinese web loggers have been censored or imprisoned are very vague and could easily be seen to encompass discussions about privacy and human rights that are held in IETF meetings. (I'll note that even the *discussion* that China enganges in censorship, or harmonization can be enough to get web sites censored.) But things will be OK for the IETF? The laws will somehow be enforced differently for us? Maybe it's horribly US- and European- centric to want the sort of guarantees one can get in a system where there is rule-by-law, and not rule-by-man, where the whims of a local mandarin can result in people being thrown in jail, because the laws are written with such an expansive wording that it's all up to the discretion of the local bureaucrat (or hotel employee). I don't think it's unfair or US- or European-centric to expect something a bit more deterministic. Maybe it's a fine distinction, but it's not about refusing to do business with a country in the hopes of changing the country, and it's not about punishing a country because we don't like their laws. It's more about (at least to me) whether or not China's legal environment meets the requirement for a safe place where the IETF can have a meeting. Some people feel safe walking in Central Park in NYC after midnight. Other people don't. But I don't think you'd say that people who avoid Central Park at night are somehow boycotting it. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
On Fri, Oct 09, 2009 at 07:04:43PM +0200, Patrick Suger wrote: I never thought it could be understood differently: anything different would be rude for ISOC. So, what you personnalité want is to be sure that whatever off topic you may want to discuss it will be permitted by the local law? This sounds like invading foreign countries and saying, hey! guys, I am the IETF, I am your law now.. In fact you may genuinely think youcann ... I don't think anyone is actually saying this. What folks are in fact saying is that out of _respect_ of Chinese local law, which apparently makes illegal many things which normally would be discussed at IETF metings, maybe it wouldn't be a good idea to hold an IETF meeting in China. The counterargument seems to be, naaah, don't worry, even though there is a contract that says these sorts of things aren't allowed, and if they happen a hotel employee can shut down the entire meeting --- they won't be enforced and don't worry your pretty little heads about such things. So if China wants to make various things illegal to discuss, that's fine. We should respect that. It doesn't mean that we should hold an IETF meeting there, though. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a future meeting of the IETF
On Fri, Oct 09, 2009 at 01:44:17PM -0700, Ole Jacobsen wrote: On Fri, 9 Oct 2009, Theodore Tso wrote: I don't think anyone is actually saying this. What folks are in fact saying is that out of _respect_ of Chinese local law, which apparently makes illegal many things which normally would be discussed at IETF metings, maybe it wouldn't be a good idea to hold an IETF meeting in China. I don't think that it is apparent that many things which would normally be discussed at IETF meetings would be illegal to discuss in China, but, yes, that is the core of the argument here. Well, one of the big problems with China is that given that exactly how its local laws will be applied isn't crisply defined, and a huge amount of discretion can be applied by a mandarins (bureaucrats) or in the case of the contract, by a hotel employee. Worse yet, its laws are very vague (where insulting Chinese culture can be enough to get a blog to get haromonized or censored) --- and by the wording of the hotel contract, enough to get us thrown out on our ear. And given that human rights is a very expansive term, and that privacy, such sa what might be described by the Geopriv wg could very will infringe on the verboten human rights restriction, it's very hard for *anyone* to give any guarantees. Which is why I used the word apparently --- not in the sense of something being apparent, but in the sense of maybe, we're not sure, and by keeping things vague the Chinese government is probably hoping that people will self-censor themselves because of the inherent vagueness of words such as 'show any disrespect or defamation against the Government of the People's Republic of China'. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] Legality of IETF meetings in PRC. Was: Re: Request for community guidance on issue concerning a futuremeetingof the IETF
On Mon, Oct 05, 2009 at 10:42:44AM -0700, Ole Jacobsen wrote: I will only answer #5 here, since I am not a lawyer (the rest will have to wait for now): I would hope the IAOC would see fit get formal legal advice on the various issues which Cullen has raised before green-lighting an IETF meeting in the PRC. (Especially since his further research seems to show that they are indeed may be some real problems!) Is that a reasonable expectation? - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Wed, Sep 23, 2009 at 03:23:57PM -0400, Marshall Eubanks wrote: As far as I know, you are not a lawyer (please correct me if I am wrong). I am not a lawyer. Ole is not a lawyer. What use is any of us doing this analysis ? I might as well ask the IETF Counsel to produce a technical analysis of LISP-ALT. I don't think that this will get us anywhere. I may not be a lawyer, but if there is a contract which says, any topics regarding human rights must require prior approval of the Chinese government, the plain reading of the contract is pretty clear, and if lawyer told me, nah you don't have to worry about the obvious wording of the contract, it's just normal boilerplate, I think I would be right to ask for a second (or third opinion). I understand that it is very hard for a lawyer to tell us whether or not there is a guarantee that we will be safe, but if there is something that is clear on the face that might be unsafe, I think it takes a fairly large amount of handwaving to say, that's not something you need to worry about in the contract. In fact, lawyers are usually telling us the opposite! Given that a number of people have already observed that comments of the form of how our protocols can be used to ensure human rights are certainly not unknown within the IETF, and it's not even clear such a comment would not be considered inappropriate, and there's a clear cause that seems to indicate that we should not even *mention* anything related to human rights without the prior approval of the Chinese government, it's clear that there will be some restriction on discussions that would otherwise legitimately take place at other IETF venues. Against that, we weigh the argument that the IETF would somehow become irrelevant if it doesn't meet in China. Personally, I have trouble buying that. Perhaps the cost of restricting legitimate discussions about how protocols might be used when it involves human rights or freedom is slight (although some might disagree with that; some might view this as a principle that's not worth compromising); but it's not clear the benefits of going to China are that great, either. A long time ago, I learned that the letter of legal agreements is in many cases less important than the intent of the parties. Maybe, but at the end of the day, the law is the law. The intent of the host and hotel may be good, but good intentions have never overruled law in a civil society which is governed by the rule of law. And the argument for why the statement *must* be present in the contract is that it is required by Chinese national law. I'm not sure which is worse, the argument that we don't need to worry about the law (thus implying that maybe China isn't actually a society where the rule of law is important), or that the law actually *does* impose these restrictions and is for real. My two cents, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Thu, Sep 24, 2009 at 07:19:15PM +0300, Jari Arkko wrote: But more generally, there are no absolutely safe options, not in China and not elsewhere. I pretty much agree wit Marshall's analysis on the motives of the various parties in this particular case, and I'd have no problem with going over there with the IETF. Granted, no place is absolutely safe. But it does seem like China is more un-safe that other potential venues with respect to free speech, if we are to take Chinese National Law at their word (and the argument, don't worry, Selective Prosecution is the order of the day in China, and they won't bother us, isn't terribly comforting). And as others have already pointed out, discussions about how our protocols are used, and issues around privacy *are* regularly discussed in IETF mailing lists and meetings. It's not just about bits and bytes. The attitude, Once the rockets go up, who cares where they come down? It's not my department says Wernher von Brown, while it does exist in the IETF, certainly isn't the only, and perhaps not even the majority, position. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meetingof the IETF
On Thu, Sep 24, 2009 at 02:57:58PM -0400, Marshall Eubanks wrote: The most obvious answer to your question is that it is not at all clear if the government would even reply or if they did, how long it would take for them to reply, and even then, how much information you would be able to take away from the reply apart from don't break the law. Do you think any other government of any other country would provide an answer in a manner and timeframe that would be at all be useful? When I worked for the US Government, it was drilled into me that we did not and could not speak for the US government. Any advice we would give was just that, and did not constrain the government in any way whatsoever. True, but you probably *could* say that you (and every other Federal employee, including the president) that to execute an oath to preserve, protect, and defend the constitution of the United States, and that one of the previsions in the Bill of Rights was this thing guarantee of Freedom of Speech. Similarly, European officials could point to the Charter of Fundamental Rights, and its guarantees of Freedom of Expression. So in answer to Ole's question, other governments of other countries *could* provide an answer in a manner (the US Bill of Rights and/or the CFR) and timeframe (immediate) in a way which is immediately useful --- and which apparently, China can not. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meetingof the IETF
On Thu, Sep 24, 2009 at 04:53:40PM -0700, Ole Jacobsen wrote: The contract clause is indeed broad, I think as a deliberate step by the hotel to protect its economic interest in the event of a shutdown. So, what remains for us to do is to set forth the actual practical arrangements for the meeting. There is more to come. I'm confused now. I thought earlier it was asserted that the clause was non-negotiable because it was mandated by Chinese National Law? That's different than saying it was a deliberate step to protect its economic interest. One of the things which seems to be very clear is that China is not a place where the rule of law holds way. To quote Wikipedia, The rule of law, also called supremacy of law, means that the law is above everyone and it applies to everyone. Whether governor or governed, rulers or ruled, no one is above the law, no one is exempted from the law, and no one can grant exemption to the application of the law. When we hold a conference where the rule of law doesn't hold sway, it means that things are not predictable. Maybe the prospective hosts have enough sway with powerful people that the plain reading of the law of what is prohibited will be bent, and a blind eye will be turned to IETF's working group's discussions, even if they violate the very broad proscriptions in the hotel contract, and perhaps Chinese National Law. All we have is the word of the host that things will be OK. Maybe the IAOC, having worked with the host more closely, is confident that things will be OK. Gee. If only every country in the world had a political system as good as yours :-) I was pretty careful to make my statement non-U.S.-centric. Certainly Europe has a strong tradition of Rule of Law, and the Charter of Fundamental Rights is a declaration which is not US-centric; indeed, it goes far beyond the rights guaranteed by the US Bill of Rights in some instances. The existence of Rule of Law and guaranteed rights of Speech or Expression seems to be fairly common feature of all or nearly all of past IETF venues. So perhaps it isn't fair to state with that insisting on this means that we are somehow assuming some kind of US-centric exceptionalism. Looking at the list of past meeting venues (Sweeden, Canada, US, Ireland, Czech Republic, France, South Korea, Austria, Japan, UK, Australia, Norway, Germany, etc.), China's characteristics are definitely new and unique for the IETF meeting venues. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
In addition to the distasteful restriction on freedom of speech placed on attendees (comments, perhaps made in jest, during the plenary or even in the hallway about the great firewall of china might cause summary ejection of the individuals or the entire groups), there are two other issues that don't seem to be addressed in the Hotel agreement. (1) What assurances if any can be given about IETF members being granted or denied visas based on blog postings talking about, say, Google or Cisco being evil due to their aiding and abetting China's censorship of the Internet made available to their citizens (not to mention those who may have in the past rendered technical assistance to those in China desiring to circumvent the Great Firewall)? (2) What sort of access will IETF'ers have to the Internet? Will IETF'ers behind the Great Firewall? What about the ability for IETF'ers to use encryption (ssh, IPSEC, etc.) to connect to their corporate Intranet? Note that encrypted tunnels could be used by IETF'ers to proxy out to get unfiltered internet access --- but will the Chinese government allow this on the grounds that they won't be able to monitor network activity for political activity? If these restrictions prevents people from being to connect to their corporate networks, it would seem to be an absolute showstopper. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Request for community guidance on issue concerning a future meeting of the IETF
On Sat, Sep 19, 2009 at 08:16:18AM +0700, Robert Elz wrote: Date:Fri, 18 Sep 2009 14:29:44 -0700 (PDT) From:Ole Jacobsen o...@cisco.com Message-ID: pine.gso.4.63.0909181236360.12...@pita.cisco.com | Whether or not we should meet in China based on principles of | free speech and such is, I think, something we need to come to | at least a rough consensus on. Actually, no, we don't, and shouldn't. If we were to start down that road we'd need to start analysing the policies of countries on all kinds of sensitive issues, such as religious freedom, the right to bear arms, compulsory military service provisions, whether or not abortion is permitted, adherence to the Kyoto pact on climate control, I think we can make a distinction between things that aren't going to affect (or are highly unlikely) to directly affect an average IETF attendee, and issues are more general in nature, or what an oppressive regime inflicts on its citizens. If there was a proposal to go to a country was highly likely to clap someone in irons and lock them away just because they were Jewish, and it would apply to IETF attendees, I hope it would be obvious that this would be a religious freedom issue that would impact our choice of that venue. Some IETF'ers might decide that they don't want to render legtimacy to a regime that denies its citizens Free Speach, and I agree with you that should be a decision that each attendee should make for its own. OTOH, if there is a legal agreement which must be signed which clearly impacts the free speach rights of IETF attendees, past a certain level, I think it is valid for us as a community to decide that maybe using such a venue might not be the path of wisdom. Whether or not the situation on the ground in Beijing is likely to rise to that level, I am not sure. Maybe people are right in that the authorities understand that if they were to be unreasonable, it's highly likely that it would be widely publicized and it would be a major black eye for them. On the other hand, having heard stories (admittedly many years ago), about someone on an international assignment in China who called his wife and talked to her in Portugese (since that was her native language), only to have a heavily Chinese-accented voice break into the line to demand, speak in English, I'd be feeling rather cautious about going to China and would probably feel that I would want to be very careful about how I spoke and behaved while in that country, far more than most other civilized parts of the world --- which wouldn't make it to be a terribly pleasant place to visit. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF74 T-Shirt Art Donated to IETF Trust
On Mon, Aug 03, 2009 at 01:16:17PM +0100, Tim Chown wrote: I have another scenario for draft-ietf-more-t-shirts-please, which is the much loved but heavily faded or worn t-shirt. I really liked my IETF55 sports-style Nokia IPv6 shirt, but it's now relegated to gardening duty. A chance to get a new version would be awesome, and while I doubt we'll do backdated t-shirts, I can imagine the IETF74 shirt we have 'source' for being similarly desirable in five years time. I agree the income to the IETF will not exactly be huge, but more people being seen in IETF shirts is no bad thing for awareness. Often seeing someone else in a past IETF shirt invites a conversation that would never happen otherwise. The T-shirt I'd really like to get a reprint of is the Story of the Mighty Vasa --- Another Failure of the Seven Layer Model T-shirt --- which I think was an IETF shirt, but am not completely certain. There are companies, such as CafePress.com, that will do on-demand T-shirts, and even return a small design royalty to the company/organization that created the design. So something like that is quite possible; finding the volunteers to organize getting the rights to the design is probably the hardest part of the exercise (and yes, the amount of money returned to the IETF would be small, and not worth doing for that reason alone). - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: More liberal draft formatting standards required
On Wed, Jul 01, 2009 at 09:00:48AM +0300, Yaakov Stein wrote: I would not be surprised if with my next machine I would find it impossible to print correctly using any of the standard utilities provided, and that I would be forced to write a program to do so. The machine after that will probably not have any languages I know, and I hope that the IETF will be able to provide (free of charge) a viewer with printing option. There may be specific deficiencies with specific operating systems that no longer no how to print ASCII documents, in which case IETF might need to provide (or at least point to) a viewer/editor with a printing option. As it stands today there are plenty of simple text editors that are available for Windows; they aren't provided by the OS provider, so they're not installed by default, but they certainly exist --- and, due to the simplicity of the RFC series' archival format, they certainly would not be hard to provide. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Beyond reproach, accountability and regulation
On Thu, Apr 30, 2009 at 03:26:02PM -0700, David W. Hankins wrote: I was very dissatisfied with the IETF's performance towards its agenda until this occurred to me. It would have helped me immensely if it were formally identified in this way (but then that would require the IETF carry a 'Philosophy Area'), and to some extent I imagine that this is also the problem some of the IETF's more vocal detractors are wrestling with; the belief that the IETF does or should follow a Socratic, Aristotelian, or even Democratic methodology, and the resulting confusion and hurt feelings to discover that blatantly Sophist rhetoric has succeeded where their deductions or even elections have failed. That's a rather interesting, and dare I say it, insightful way of looking at it. Maybe (and I'm only half saying this in jest) Zen and the Art of Motorcycle Maintenance should mentioned as recommended reading to the Tao of the IETF --- and that what we are after, is Quality in our standards. Quoting from a description of that book: Much of the book focuses on a rather surprising topic: quality. We think of quality as a measure of a product or a person, and we feel the right to make judgments about it because it is clear when something is of quality or is not. The narrator recounts taking his motorcycle to a workshop and reluctantly handing it over to a crew of young men playing loud music. Instead of fixing the machine, they butcher it, and he learns a lesson: it is the attitude towards a technological problem, not simply rational knowledge of how a thing works, that makes all the difference. Merely going by the manual is a clumsy, low-quality approach. Thereafter, he did the work himself. Quality cannot be defined in a rational way, it can only noticed when it happens. Yet quality is everything: the difference between someone who cares, and one who does not; between a machine that can enrich your life, and one that explodes into a heap of useless mental. Yet instruction manuals, the narrator observes, totally leave out of the picture the person who is putting something together. If you are angry or unmotivated, you will not succeed in tuning the machine or finding the problem, but if you patiently put your mind into the place of the original designer, you come to see that a machine is really just the physical expression of a set of ideas. Paradoxically, it is only when you go beyond the classical idea that we can separate our mind from the world, that 'objects' begin to come alive. Quality is appreciated not as a thing, but as the force that drives the universe. The narrator notes, Obviously some things are better than others.but what's the 'betterness'? His epiphany comes in reading the ancient Tao Te Ching, when he realizes that what we call Quality, or 'betterness', is the same as the Eastern concept of 'Tao', the universal power or essence which can never be identified as such, but whose presence or absence makes something good.[1] [1] http://butler-bowdon.com/zen-and-the-art-of-motorcycle-maintenance.html Another way of putting this is the oft-made observation that Engineering is the IETF's middle name, and that very often, especially when the problem is heavily constrained, the engineering tradeoffs that we often have to make are very much a matter good taste and judgement, and not necessarily something that can decided using traditional Socratic or Aristotelian modes of argumentation. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: pickpockets
More personal comments, based on having lost a laptop to a two-man team at the exit to the Brussels train station in the last two months I got hit upon arrival to the country, where I was badly jetlagged after arriving early into London Heathrow, and then taking a connecting flight to Brussels, and being badly short on sleep before starting the travel in the first place. So be especially vigilant on that first day, when your defenses are down and if you are desperately tired and/or jet lagged. In my case, one of them slimed the back of my jacket with spit and a what appeared to be mouthful of partially chewed sandwidch, and the other one tried to sell me postcards while babbling in French and pretending not to know English. When you're tired, grumpy because the train station is badly labelled and you're wondering whether you took the right escalator or not, and are generally lost, it's ridiculously easy for a pickpocket to overload you enough that while you thought you should know better, you don't. Other lessons learned/reinforced --- (1) back up your laptop before leaving on an trip, (2) keep a backup copy of your presentation on a USB stick stored separately in the luggage or on some system accessible outside of your firewall, so you don't have to try to regenerate it on the fly, (3) keep all sensitive information encrypted at rest on your hard drive, (4) never, *ever* set down a shoulder bag even under extreme provocation, (5) if something strange happens to you, don't stop, don't turn, just keep walking briskly away. Personally, my experience of Belgium was badly tarnished as a result of being hit by pickpockets, and I'm not at all keen on wanting to go back as a result. So a word to the wise --- be careful out there it really can happen to anyone, especially those who thought they were knew how to be careful enough. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NoteWell use pertains to the IETF Mailing Lists too - but hey - anyone with half a brain should have known that - WAS: Re: Subscriptions to ietf-honest
On Tue, Mar 24, 2009 at 10:25:50AM -0400, Melinda Shore wrote: Todd, if you can't figure out the differences between an IP address and an email address, delivering packets and delivering email, well, I don't know. And Dean's *not* the IETF. The IETF has some people acting in designated capacities but Dean isn't one of them. I agreed to receive email from IETF mailing lists. I did not agree to be put on any mailing list created by any random crank with an axe to grind. Unfortunately, ignoring random cranks with an axe to grind seems to be the only thing that helps. Anything else just encourages them. :-( - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
On Tue, Feb 17, 2009 at 07:24:20PM -0800, Lawrence Rosen wrote: I've made no such assumptions. I've submitted a couple of process documents from W3C that can be modified easily to fit the IETF model. I thought John and Steven would be satisfied with a rough draft. Sort of like Windows might provide a model for a Linux open source program, without the actual code being yet written. :-) Well, a key part of the W3C model is that you can't even post on a wg mailing list without you and/or your organization signing contract (I believe they require an ink signature, but I'm not 100% sure of that), or being explicitly invited by the chair as an guest or invited expert, and with everyone in the wg being told that any postings from said guest must be treated as unclean, unclean! since they haven't signed the ink contract. I will not, wryly, that having a closed mailing list does solve the FSF problem, since they will no longer be able to spam our mailing lists. The question is whether the cure is worse than the disease. However, for you to say that this isn't a big deal to adapt to IETF mechanisms is handwaving --- unless you're saying that closed workgroups that require legal contracts to be signed before anyone is allowed to participate is a good thing ? - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Previous consensus on not changing patent policy (Re: References to Redphone's patent)
On Mon, Feb 16, 2009 at 02:11:26PM -0800, Lawrence Rosen wrote: But are the 1,000 or so emails in recent days from the FSF campaign not a loud enough hum to recognize that our IPR policy is out of tune? This is not the first such open source campaign either. IETF needs a more sturdy process to deal with IPR issues. Please consider the suggestions now on the table. Given how badly misinformed the FSF and their 1,000 blind followers were --- no, it's not even a hum. More like the sound of a Concord taking off if an IETF meeting happened to be located in a hotel which was unfortunately located too close to an airport's runways. Full of sound and jury, signifying nothing... :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
On Tue, Feb 17, 2009 at 05:40:46PM -0800, Lawrence Rosen wrote: Steven Bellovin wrote: All that said, the above is my strawman that I've just torched. This is why we need a draft -- until we have one, we won't know if it's a plausible, useful idea or not. In fact, a metadraft -- one that simply set out the questions that a concrete proposal should address -- would be a worthwhile contribution in its own regard. In honor of open source, I'm glad to submit someone else's work as my first draft: http://www.w3.org/2004/pp/psig/. This is an effective working model. I'm sure it would have to be revised to fit IETF's more democratic operations. This model works if you have closed working groups and no one is allowed to participate without first going through a huge amount of bureaucratic rigamarole, and where someone can't even poke their head into a meeting room without being explicitly invited by the chair. It doesn't work at all in an IETF model which is much more open. So you've done the equivalent of submit Windows source code and assume that it can be ported to a Unix system left as an exercise to the reader care to give a detailed suggestion about *how* it could be revised to work with the IETF's more open procedures, and still be useful in terms of meeting your stated goals? - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: ANNOUNCEMENT: The IETF Trustees invite your comments on ...
On Mon, Jan 26, 2009 at 07:36:29AM -0800, Dave CROCKER wrote: Andrew Sullivan wrote: Wha the work-around appears to me to provide is a way for contributors to say, But maybe I don't have them all. From my point of view, that's less good than releasing the contributor from needing to make such claims in the first place, but it's an improvement. ... What's unusual in this case is that every contributor, by virtue of having to assert that he or she has obtained the relevant permssions, is _also_ subject to those lawsuits. +1. This nicely highlights the underlying problem with the approach has so far been taken: It expects far too much from people who are, in actual fact, acting as agents of the IETF. The fundamental problem is that RFC 5378 conflates two separate things. (1) People who make contributions (normally authored by themselves) to the mailing list, and (2) people who take contributions/suggestions made on the mailing list, in face-to-face meetings, et. al., and put them together as an author/editor of an I-D. Both are defined as Contributors in RFC 3978, because contributions are defined as both as offerings of text to the mailing list and collation/editing of these offerrings to form an I-D. In both cases, to quote RFC 5378... The Contributor is further deemed to have agreed that he/she has obtained the necessary permissions to enter into such an agreement from any party that the Contributor reasonably and personally knows may have rights in the Contribution, including, but not limited to, the Contributor's sponsor or employer. The problem is the level of due care necessary such that he/she can warrant that permissions has been obtained is not defined. Is the reliance on RFC 5378 sufficient to deem that permissions has been obtained. For example, if Fred Flintstone submits text to the maliing list, can I presume that he/she has received a copy of the Note Well and has therefore has given permission for his text to be used in the I-D? If he didn't, will I be liable for his failing to adhere to RFC 5378 if I submit an I-D containing Fred's text? And am I as the I-D author/editor required to provide proof that I have obtained the necessary permissions? If so, and if I will be held legally liable, then I had better keep the I-D under source code management, and reference each message ID from the mailing list whenever I take contributions and put them in the I-D. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Editors vs Authors vs Contributors, was: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
On Fri, Jan 23, 2009 at 09:43:23AM +1300, Brian E Carpenter wrote: Because of the IPR implications, that probably should also include contact info, just as for authors. That would only arise for pre-RFC5378 text that is subject to the disclaimer clause *and* fails a fair use test. But it isn't much use anyway - the contact info in almost every older RFC is obsolete. Well, it might also be useful post RFC-5378 if there was some claim that someone had contributed text that was copyrighted by a third party, in violation of IETF's policies. But in order for that to be useful, the editor would have had to have kept the document under some kind of source code management system, or a long, painful search of the mailing list archives would be necessary to see *who* contributed the text in question, so the issue of who had cribbed copyrighted text from whom could be clarified. And of course, you're right that contact information changes so rapidly that it would almost certainly be obsolete. Fom a practical perspective, obtaining at least the e-mail address and corporate affiliation given a particular contributor name isn't hard, at least at the time that he/she was participating in the working group. The hard part is knowing for example, if ATT were to come wanting to hunt down who was responsible for including exit 0 in some RFC (since as we all know that is an unpublished, proprietary source code subject to trade secret per ATT's Unix sources for /bin/true :-) that there be some way of figuring out who was responsible for originally contributing that specific piece of the spec. If it turns out that person posted the text came from an ATT.COM address, and it could be shown that he/she was given due notice of IETF's policies, that would of course be highly useful; but you almost need to have an SCM or be prepared to do a huge amount of searching of mailing list traffic and face to face meetings minutes to be able to accurately track attributions at that granularity. Ultimately, I suspect the list of contributors is a good and polite thing to do out of courtesy, but it's not all that useful from an IPR point of view. Even if there was code that you wanted to use from a pre-RFC5378 text, you wouldn't need or want to contact *all* the contributors; you would want to know who contributed the portion of the RFC containing the code that you wanted to use in an implementation (either proprietary or open source). - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
On Tue, Jan 20, 2009 at 03:20:20PM +0100, Tom.Petch wrote: Underlying this, I believe that if only the IPR WG had not had to spend so much time discussing and re-discussing and re-re-discussing ... this issue, then may be, just may be, we would have had more time to focus on the transition arrangements that we identified the need for in RFC5377 s.3. In which case, this thread and all the other related ones would never have occurred. So I wasn't on the IPR working group, but it seems to me that there are two separable issues. There is the question of *which* license to use for contributions (which might or might not vary based on type of contribution, i.e., text vs. code), and then there is the question of whether we are sticking the entire legal liability and respponsibility onto the I-D editors/authors to guarantee/warant that the entire document can be released under the the new licensing requirements, and that relates quite strongly to the transition issue. Was that second issue discussed by the IPR wg? - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
On Wed, Jan 21, 2009 at 04:19:08PM +0100, Simon Josefsson wrote: However, the theme were present in several discussions about simplifying the procedures. One link (but probably not the best one) would be: http://thread.gmane.org/gmane.ietf.ipr/3738 Implicit in that argument is that contributors release their own contribution under a license, and do not vouch for anyone else's contribution, and that others can re-use the material under that license. This is the normal procedure in the free software community. Um, I just looked at that thread, and it was talking more about whether or not SDO's should be allowed to fork an RFC specification without getting prior permission from the IETF or not, and worries about fake RFC's. That has nothing to do with shoving all of the liabilities associating with assuring that all contributions following the IPR responsibilities onto the I-D author/editors. Maybe you thought it was implicit in the argument, but it certainly wasn't obvious to me. So if your goal was to advance that point of view, it probably wasn't the best strategy as an advocate. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees inviteyour review and comments on a proposed Work-Around to thePre-5378 Problem
On Wed, Jan 21, 2009 at 10:14:30AM -0600, Spencer Dawkins wrote: (3) I would strongly discourage spinning up a General-Area working group without adopting the workaround - as an editor, even if I thought all contributors had granted 5378-as-it-exists-today rights, I'm not sure why I would make such a declaration. What if I was wrong? I know what *I* would do, if I were editing a I-D document in this post-5378 regime. I'd put the darned thing under source control, and in each changelog message I would include a reference to the message ID and author names for each textual contribution that I didn't personally author. That would hopefully control the legal liability I would suffer if someone tried to sue me claiming that I had somehow included text which violated copyright in some way, since I would be able to demonstrate provenance at least to who actual contributed the text to the wg mailing list. I still might end up having to sell my house to defend the lawsuit, but at least I would hopefully not lose my house as a result of making the promises required by RFC 5378 --- at least I would hopefully be able to take down whoever had misappropriated the text with me. :-) In short - please do something quickly, because the current situation is making things harder for people who want to get work done in the IETF, and that should trump every other consideration, IMO. Indeed; I was only partially serious when I suggested that the IETF trust should indemnify or otherwise provide insurance to I-D authors. RFC-5378 is requiring them to take on potentially fearsome liability risks, even if we're not dealing with legacy RFC's from the pre-5378 era. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
On Fri, Jan 16, 2009 at 07:04:13AM -0500, Marshall Eubanks wrote: This raises a question. The IETF publishes relatively little code compared to the millions of lines of open source code out there. How do the large open source projects protect and indemnify themselves and their participants in case someone takes some code they don't own, post it to a CVS, and it winds up in (say) the Linux kernel ? For the Linux Kernel, we use the Developer's Certification of Origin system, which was the Signed-off-by: headers I demonstrated. There are also code-scanning tools available at sites such as Fossology.org (a working group of the Linux Foundation). A lot of this will be noticed by humans doing code review; for example, Microsoft code usually decorates its variables using Hungarian Notation (i.e., szName), and most OSS projects don't use that coding convention, so code which looks horrible and/or causes unpleasant flashbacks will raise red flags. :-) That being said, this is a problem which common to proprorietary software as well as open source software. More than once, I have been contacted by companies doing due-diligence before, during, and after a corporate acquisition, when they had found copies of GPL'ed code which I had authored, complete with my copyright statement and This code may only be copied under the terms of the GNU Public License... in proprietary code that was shipped as product by the company that had just been acquired. Yes, there *are* programmers that clueless out their writing code for proprietary software companies - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
On Thu, Jan 15, 2009 at 08:24:08AM -0500, Marshall Eubanks wrote: On Jan 15, 2009, at 7:09 AM, John C Klensin wrote: If someone stood up in a WG prior to whenever 5378 was effective* and made a suggestion of some length, or made a lengthy textual suggestion on a mailing list, and I copied that suggestion into a draft without any paraphrasing, a plain-sense John, I am not a lawyer, you are (AFAIK) not a lawyer, and if the IETF counsel says otherwise, I would just let this one lie. The reason why I do not agree with this reasoning is that these rights are claimed through authorship. If I do not claim authorship in your draft because you use my text, when I have ample opportunity to do so, then I have (in my opinion) effectively lost them, especially in this context (where there is a note well, an assumption of joint contributions, etc.). So it's a problem if every single I-D and RFC author is going to have to consult their own counsel before deciding that won't get into legal trouble when guaranteeing that all of their text is appropriately licensed. So whether or not I am I lawyer, and whether or not the Berne Convention very clearly states that copyright rights are automatically enforced, and do not need to be explicitly claimed, and whether or not the Note Well is enough to override the Berne Convention, John's position that he wants to be conservative enough not to make guarantees that might expose him to legal liability is a reasonable one. I don't think it's fair to say, I'm not a lawyer, and you're not a lawyer so you should do something which you fear exposes you to legal risk --- especially when all of the IP training many of us have gotten have basically told us that the Berne Convention explicitly states that you don't have to claim copyright to get copyright protections Yes, I am sure that there are corner cases here, but one thing I have found about legal affairs is that there are always corner cases. No legal matter is ever sewn up 100%, and judges actually do take into consideration when things are done on advise of counsel. We have it, we should use it. Has the IETF Counsel actually given explicit legal advice to all IETF contributors (which would have legal liability implications for the IETF Trust if said advice was wrong, as I understand things) that the Note Well to guarantee the transfer of RFC 5378 rights for text taken from IETF mailing list discussions or at an IETF meeting? Better yet would be if the IETF Trust was willing to ***indemnify*** I-D and RFC authors that they are on firm legal ground for asserting that they have all RFC 5378 rights when they take text from an IETF mailing list discussion or IETF face-to-face meeting, on the basis of the Note Well. After all, it is the IETF Trust which is requiring I-D and RFC authors to make this legal guarantee, so one might assert that in a fair world they should take the legal risks associated with that guarantee. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
More to the point, the question at hand was to what happens to mailing list discussions (or face to face discussions) which took place *before* RFC 5378 was published. John's observation was that it doesn't matter when the I-D or RFC is published, even if it is published *after* RFC 5378, if it contains text that was derived *before* RFC 5378, regardless of whether it came from an RFC, I-D, mailing list discussion, or face-to-face discussion, the RFC 5378 rights that a Contributor might provide wouldn't exist. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC 5378 contributions
On Thu, Jan 15, 2009 at 11:50:46AM -0500, Marshall Eubanks wrote: Consider the threat model here. This threat applies ONLY to material that the Trust licenses to third parties (such as, say, the IEEE) for inclusion and modification in their standards. (Just reprinting or translating an RFC is not at issue.) So this licensing to third parties is not automatic; which makes sense in terms of letting the IESG to have a control point before allowing another standards body to take over a standard (or try to take over a standard). However, that presumably wouldn't be tree for allowing text or code to be used in implementations, open source or otherwise --- I assume that wouldn't require prior permission first, right? If the Trust does NOT license your material to third parties, then there is no infringement, no one with standing to sue, and no risk to authors. It may be necessary for the Trust to state that they will not assume 5378 to be in place for this purpose until there is a replacement. (In that case, if the IEEE or some other body wants to take over an RFC and modify it, they will have to get explicit permission from all authors until there is a replacement for 5378 in place, just as they did before 5378 as put into place.) My understanding is that the Trust is responsible for these licenses, and so they could just (in their best judgement) refuse to issue them without further conditions. So there probably isn't much risk for a standards bodies wanting to take over a MIB, for example, But what about someone using pseudo-code from a RFC where the RFC editor is required to make an assertion that he/she had all of the rights, and the code or pseudo code was contributed by a third party who copied the code from some Microsoft source they had access to while they were a graduate student? Or (and this is my opinion), maybe the authors should only warrant _their work_ as being subject to such licenses, and put the burden on the Trust to obtain any necessary approvals from other parties, only alerting the Trust to the extent they know of such prior authorship. My understanding is that this would require a 5378bis. That I think is the key; each person can only warrant what they themselves have authored. Something that might be worth looking at is the Developer's Certification of Origin, which is how Linux Kernel developers deal with contributions for the Linux Kernel. Anything which gets incoproated into the kernel must have a Signed-off-by, like this: Signed-off-by: Theodore Ts'o ty...@mit.edu What this mean is an explicit assertion of the following: Developer's Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved. This would obviously have to be modified for the IETF's purpose, but what's nice about it is that each Linux Kernel Developer is only making assertions about things which he or she has personally has control over, and by using the Signed-off-by chain, it's possible to see the handoffs as the patch was passed up the chain from one developer to another, i.e: commit 166348dd37a4baacfb6fe495954b56f56b116f0c Author: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Date: Mon Sep 8 23:08:40 2008 -0400 ext4: Don't add the inode to journal handle until after the block is allocated Make sure we don't add the inode to the journal handle until after the block allocation, so that a journal commit will not include the inode in case of block allocation failure. Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com Signed-off-by: Mingming Cao c...@us.ibm.com Signed-off-by: Theodore Ts'o ty...@mit.edu - Ted ___ Ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Sun, Jan 11, 2009 at 04:09:54PM +0100, Simon Josefsson wrote: I would agree with you for the 2-3 sentences scenario, but that's missing my point. I would fully disagree when it comes to 2-3 paragraphs, 2-3 pages, or entire I-D's. I believe the latter is the reality with several free software projects, including the Linux kernel. 2-3 paragraphs would probably still be fair use. I'm not aware of any place in the Linux kernel where there was more than a few paragraphs quoted from RFC's. There were a few projects that included full verbatim copies of RFC's for reference/documentation purposes, although most of those have been removed due to the fact that previous RFC permission statements were not compliant with the Open Source Definition, and so distributions such as Debian required that such full copies of the RFC had to be stripped from the source packaging. That was never the case with the Linux Kernel, however. Some Debian Free Software Fanatics are having a field day with firmware binary blobs, but not with any I-D's or RFC's as far as I am aware. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Sat, Jan 10, 2009 at 02:37:50PM +0100, Simon Josefsson wrote: We do have precedent for include code that has explicit open source licensing rights. For example, the MD5 implementation in RFC 1321 has an explicit BSD-style license. Sure, but under the post-RFC 2026 rules that would not be allowed since the rules do not permit additional copyright notices to be present in documents. There has been exceptions and mistakes, so there are post-RFC 2026 documents with other licensing information in them, but the IESG/IAB has also rejected including free software code in RFCs. Allowing BSD-like code to be included in RFCs would be great step forward. It is not allowed under the RFC 5378 license either, at least not generally when the code was not written by the document author. This should clearly be fixed in RFC 5378-bis, in my opinion. If the goal is to allow code to be allowed in Open Source Software, then requiring a maximally compatible OSS license for code makes sense. But requiring for random protocol text, especially if this is going to make reuse of older RFC's text, seems to not be a great cost/benefit tradeoff. A more realistic approach may be to think about how text in RFCs are used. Text often end up in free software projects as comments. This is useful and helps get the RFC implemented correctly in a more maintainable fashion. The goals of the IETF is furthered by this, I argue, so it is disappointing RFC 5378 does not solve the problem. At least in the linux kernel, quoting a 2-3 sentences of an RFC in comments is common practice, even before RFC 5378. It is also been done with great frequency in documentation, magazine articles and journals, and so on. Fair use takes care of this problem, and there I don't think even the most insanely paranoid and unreasonable corporate lawyer would think that 2-3 sentences quoted in manuals, code, etc., would be unreasonable. Certainly this is something where we have over two decades historical practice, and if anyone thinks an IETF contributor or company would be suicidially idiotic enough from a Public Relations point of view to try to sue someone for using 2-3 sentences when this would be pretty clearly fair use, and the reputations of said IETF contributor or company would be pilloried in the press, I would gently suggest that whoever is worried about is greatly disconneted from reality, if they were to think about the risks involved. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
On Fri, Jan 09, 2009 at 06:52:40PM -0500, Joel M. Halpern wrote: My own take has been that the code reuse problem is the dominant problem. Document transfer outside the IETF is sufficiently rare that I would agree with Fred that not solving that is fine. If it really is the case that the *only* two problems was document transferoutside of the IETF (rare) and code reuse problem (what percentage of documents are are actual code that would require special case licensing --- small) it's actually pretty amazing that the problem was allowed to balloon to cover **all** text for **all I-D's and RFC's**. There's the old saying --- an engineer takes a large problem and break it up into several smaller problems, and having solved each of the small problems, solves the overall problem; a bureaucrat takes several small programs, and tangles them all together into one, gigantic, intractable problem. This also means that from my personal perspective, a solution that says (loosely based on a suggestion from someone else in a side conversation) that 1) If you can, you grant 5378 rights 2) If you can't, you grant the old rights, as long as there is no code in the document 3) If there is code, get the rights to the code so people can actually use the code in the RFC to implement the RFC. (MIBs are already covered, but we have lots of other kinds of code.) We do have precedent for include code that has explicit open source licensing rights. For example, the MD5 implementation in RFC 1321 has an explicit BSD-style license. How much code is there, really? I suppose pseudo-code might be a gray area tht will depend on how paranoid of a lawyer you are dealing with. One who uses the argument that copyright can not protect ideas, just the expression of the idea, will probably say that it's OK. One who tries to draw a parallel to translations as derived works might be more concerned. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
On Tue, Dec 09, 2008 at 11:23:10AM -0800, Dave CROCKER wrote: Evidently you believe that the anecdote you posted proves something, but I am not sure what. Some others have suggested that it proves something which, I strongly suspect, is not what you had in mind. Perhaps you can clarify the purpose of your note. How should it be incorporated into the IETF's deliberations? The point I was trying to make is that there seems to be an inherent assumption by some people, perhaps because the people who make these assumptions run large mail servers, that the problem with someone who is wrongly blocked rests solely with the sender, and not with the utimate recipient, or with the mailer operator. It's essentially an attitude of you have no _right_ to send us e-mail, and if we make an (inevitable) mistake, and blacklist list you incorrectly, it is up to **you** (the sender) to go to us on bended knee and prove tht you are not an evil spammer, or an incompentent Windows desktop owner who has let their machine be taken over by a botnet. I'm sure they feel magnaminous when they offer some method of approaching them on bended knee, hoping that that they will give you permissionto send e-mail --- whether it is via a phone number or whether it is via placing an international phone call and paying $$$ to some Austrialian PTT to beg and plead to be removed from some IP blacklist --- and I am still not convinced it is the best indetifier when deciding whether or not blocking *all* mail from a particular IP address. You may be trying to place the burden on me, but consider that we are merely getting assertions from the other side of the aisle as well. My main point, though, is that in some cases, the ultimate recipient may have a much greater interest in receiving the e-mail than the sender, and so the model of requiring the sender to assume the burden of proof and go on bended knee to the mailserver administrator to let their e-mails through may not be a particularly good model to use as the basis for making recommendations for best practice. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
How I deal with (false positive) IP-address blacklists...
This doesn't work for most people, but I had fun composing this response, and coming just a few weeks after people claiming that IP-based blacklists work well, and rarely result in false positives, I felt I just had to share. :-) - Ted ---BeginMessage--- Hi there. Your mailer appears to have my one of the addressed used by primary mailhub, 69.25.196.31 (it reverse-resolves to www.church-of-our-saviour.org.). Its primary ip address and hostname is thunk.org, 69.25.196.29. You can see who I am here: http://thunk.org/tytso If you use any amount of Linux on your systems, I am the first North American Linux Kernel developer, and the maintainer of e2fsprogs, the filesystem utilities for ext2/ext3/ext4. This bounce took place because I replied to some user who apparently has a mailbox on gondor.apana.org.au, on the Linux Kernel Mailing List. The way I see things, I provde *way* more services to your users than you do to me, so I don't see any reason to place an international phone call to get my IP address un-blacklisted. If one of your users or one of your staff members needs my help to fix a Linux kernel problem, or to unscramble an ext2/3/4 filesystem, or an invite to the some future Linux Kernel Summit, and they can't receive my e-mail, that is *your* problem, not mine. I've arranged to make sure this gets routed via an mit.edu mailhub, but that's about all I plan to do to resolve this problem. Your move. Best regards, Theodore Y. Ts'o Linux Foundation Fellow and Chief Platform Strategist STSM, IBM Linux Technology Center Medford, Massachusetts (617) 245-5616 (781) 391-2699 (fax) (781) 526-0121 (cell) ---BeginMessage--- This message was created automatically by mail delivery software. A message that you sent has not yet been delivered to one or more of its recipients after more than 24 hours on the queue on thunker.thunk.org. The message identifier is: 1L9Ulw-0001Yz-O5 The date of the message is:Sun, 7 Dec 2008 20:18:51 -0500 The subject of the message is: Re: Runaway loop with the current git. The address to which the message has not yet been delivered is: [EMAIL PROTECTED] Delay reason: SMTP error from remote mailer after end of data: host rhun.apana.org.au [64.62.148.172]: 451-sender IP address 69.25.196.31 is locally blacklisted here. If you think 451 this is wrong, please call +61289874478. No action is required on your part. Delivery attempts will continue for some time, and this warning may be repeated at intervals if the message remains undelivered. Eventually the mail delivery software will give up, and when that happens, the message will be returned to you. ---End Message--- ---End Message--- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
On Tue, Dec 09, 2008 at 05:49:02PM +1100, Mark Andrews wrote: They didn't say why they had blacklisted that IP so there is no way to determine if it was a false positive or not. That also make the request to phone if the listing was in error pretty hard to determine. Well, it blocked a legitimate e-mail message, so by definition the rejection was false positive. I've also checked a number of DNSBL's, and no one else seems to have black-listed my IP address, except these jokers. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: How I deal with (false positive) IP-address blacklists...
On Tue, Dec 09, 2008 at 06:24:11PM +1100, Mark Andrews wrote: Well, it blocked a legitimate e-mail message, so by definition the rejection was false positive. I've also checked a number of DNSBL's, and no one else seems to have black-listed my IP address, except these jokers. Define legitimate. One that conforms to the RFC's? One that you send? One not containing advertising material? One that does not contain unsolicted advertising material? One about the content of the soil on the moon? One that doesn't discuss the content of the soil on the moon? Well, the intended recipient, is a Linux Kernel Developer. He posted a message on the Linux Kernel Mailing List, about Linux Kernel Developement. I responded, on-topic, with a message that had no advertising material, soliticted, or unsolicited. I think that meets the definition of legitimate e-mail, don't you think? It seems pretty clear the recipient probably wnated to receive it, and in this case, an IP address-based blacklist is causing him not to receive the e-mail. It has been made unreliable for him. I also happen to be the founder and program committee chair of the Linyx Kernel Summit, which brings together the top 75 kernel developers to the summit, and for which the competition to receive an invitation based on merit is highly competitive. Heck, some companies pay $25,000 USD and up in order to receive a sponsored invite to the Kernel Summit. Occasionally, I will send an invite to a fellow kernel developer, and it will get bounced due to some bogus false positive spam filter (very often, it tends to be an IP-based filter). If I'm feeling nice, I'll try to route around the brain-damage. If I'm feeling really annoyed, I'll just drop the bounce on the floor, and assume the developer in question didn't really want the invite, or was too stupid to find a reliable ISP/mail handler, so they don't deserve the invite. This happens to be relatively unique position where I have far more power than the recipient, and in many cases they are much more interested in receive e-mails from me than I am in bothering to figure out why some bogus IP-based address filter bounced my mail. Basically, if they would badly want to receive it, and some bogus technology has made e-mail unreliable, I'd consider that a false positive rejection of a legitimate e-mail message --- and in general, it's their problem, not mine. Any attempt I might make to work around the breakage is due to my charity, not any obligation on my part. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advice on publishing open standards
On Fri, Nov 28, 2008 at 02:28:23PM -0500, [EMAIL PROTECTED] wrote: Second, Unicode is used with sequential scripts: one character after another. Our script is spatial: the words are characters written in space based on coordinates. The words are sequential, but not the characters. Even if we were part of the Unicode standard, I do not believe existing applications could properly edit or display the words. I did a quick examination of your specification, and I couldn't find any documentation for how your control chracters and spatial coordinate system works in practice. Given that this seems to be critical for interoperability and for anyone else to be able to write software that utilizes your character set, it appears to me your specification may be incomplete. Something that may be useful would to be try to get someone else to create an independent implementation that can at least display your script, going solely from your specifications. That would be a very good sign that the specification completely specifies your new writing system. After all, the whole point of standardizing something is to allow multiple people to create implementations that can interoperate. So if you only have one implementation utilizing your scripting system, and you haven't yet built up an implementation community interested in utilizing your writing system in multiple applications that need to be able to interoperate with each other, standardization efforts may be a little premature. The other comment I will make is that using a writing system which isn't compatible with existing writing systems which are purely left-to-right (or right-to-left) will significantly hamper the development of application programs that can support your SignWriting. It means that instead of being able to use an unmodified version of, say, Open Office or some other word processing software, you will need to implement either your own word processing software, or at the very least, need to modify existing application programs one at a time to support your new writing system. I know you've spent a lot of time putting together a system which very accurately models the physical movements of signing. This is an approach similar to using a purely comprehensive description of every possible audible sound/phomeme that could be used in a spoken language, such that one writing system could be used for recording sounds used by all spoken languages --- the International Phonetic Alphabet (IPA) is one such system that attempts this, for example. However, this might not necessarily be the most efficient way of encoding sign language, and if it requires the spatial coordinates into characters, this might not be the most appropriate encoding system for everyday use by deaf people, just as most people do not use the IPA for encoding spoken languages for everyday common use when they are writing letters, books, sending e-mail, etc. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: uncooperative DNSBLs, IETF misinformation (was: several messages)
On Fri, Nov 14, 2008 at 04:08:50PM -0500, Al Iverson wrote: Is this unique to DNSBLs? If not, then why does it merit deeper consideration in the context of DNSBLs? what you are arguing is that rather than trying to address the harm done by DNSBLs, IETF should ignore that harm by ruling it out of scope for the current discussion. I suggested no such thing. I asked for the opposite -- help somebody who doesn't get it understand exactly what the connection is. I think the issue of the badly-run DNSBL's can be handled handled by amplifying the first paragraph of the Security Considerations section. Currently, it merely talks about the most blantent problems caused by a DNSBL causing all mail to be rejected, or no mail to be rejected. It doesn't talk about DNSBL's using different criteria than what they have advertised for their list, or that a potential DNSBL could use the trust given to mail receivers to explicitly block an IP block in retaliation for criticism or to pursue some other vendetta. Mentioning that these things can and have happened I think is simply acknowledging the obvious, and that a poorly chosen DNSBL can cause great harm. I would also encourage the how to run a DNSBL responsibly to be published at the same time, so that draft-irtf-asrg-dnsbl could reference the this is how you do it right (while acknowledging the only out of band mechanisms can be used to ensure that a DNSBL operator is truly following the criteria they claim to be using). This of course ignores the question of whether a document which is intended for the Standards Track should be abusing DNS 'A' records or not. It may be that a much better approach is to put this on Informational describing the current state of affirs, warts and all, and then to create a better document which is Standards Track later on. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Context specific semantics was Re: uncooperative DNSBLs, was several messages
On Fri, Nov 14, 2008 at 01:38:54PM -0800, Ted Hardie wrote: If we are documenting practice and nothing more, then the publication stream can move to informational and text can be added on why a new RR, which would normally be expected here, is not being used (essentially, inertia in the face of 15 years deployment). If inertia over many years' deployment means that it's essentially impossible to change things, then maybe it's hopeless to move to IPv6... (Oh, wait maybe that's why Doh! :-) Seriously, it's not obvious to me that it's *impossible* to change. It wouldn't be that hard for DNSBL to carry the information via the old and new RR records, with the new RR's carry additional information --- and given that MTA's have to be configured to use a particular DNSBL's, this is just one additional bit to indicate whether they should use the old or new RR record --- and for bonus points, there could be some way of querying the DNSBL, perhaps via a top-level TXT or SOA record, to indicate whether a particular DNSBL supported the new RR's or not. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Mon, Nov 10, 2008 at 05:12:56PM +, Steve Linford wrote: I certainly agree that there are hundreds of small DNSBLs run from kid's bedrooms which list on incomprehensible wildly over-broad policies and that such DNSBLs are both antagonistic and useless and as a result are used by almost nobody - that's 'market force'. But to pretend that the dozen major DNSBLs make listings based on unauthenticated rumor or because the IP did not have 'mail.' or 'mx.' is just silly mud-slinging itself based on equally unauthenticated rumor and is especially odd if it's coming from within IETF itself. Let me get this straight. It's OK to block e-mail messages on the basis of unauthenticated rumors, but now you are complaining that it's somehow dirty pool to block a standard based on the same thing? After all, it's the same argument; there's a lot of evil e-mail messages out there; the cost of letting even one of those messages through is unacceptable, so false positives are OK. Similarly, there are a lot of bad ideas out there, many of which have folks clamoring to have them be standardized, just as spammers hope to get people to visit their spamvertised web sites. And in both cases, it's just business I have no problem with the IETF documenting the world as it exists. That's what an informational track RFC does. There's a process by which a specification gets annointed to become a standard, and others more eloquent than I have already pointed out the dangers of trying to skip steps in the standardization process. Questions like, so how does this work in the face of the expanded IPv6 address space, ideally should be addressed earlier during the standardization process, and not in last call (where, oh well, we'll just block the whole /48 or /32 might have unfortunate side effects not forseen yet) --- but which don't make sense if the goal is to document existing practice. The fact some DNSBLs are in widespread use (I can speak only for Spamhaus, our DNSBLs are today used by something in the region of 2/3 of internet networks) is good reason why it's important to publish a standard and format for the technology. There's a big difference between use and Use. If a spamassassin configuration (by default) uses a DNSBL to add a point or a fraction of a point to a spam score, where it might take a spam score of 10-15 before spam is dropped, that's a very different usage model than someone who, on the unsubstatiated word of SORBS or APEWS, drops the e-mail on the floor where it is never seen again. And for those who would argue that it's not their problem how the DNSBL is used, since after all that's the responsibility of the folks using the DNSBL, I'm reminded of the line from the Tom Lehrer song: Vonce the rockets go up, who cares vhere they come down? It's not my department, says Verner von Brown. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
Speaking as someone who runs their own private mail server (thunk.org), and having suffered from collateral damage when an entire ISP range was listed, and where I had absolutely no way of getting off a DNSBL that operating in a liability-free zone, with administrators who refused to communicate with me, and where I had no way of getting off the list, and thus had my e-mail blocked(*), forgive me if I'm a bit less sanguine than you about the suitability of DNSBL's, and whether your BCP will have any effectiveness whatsoever. If DNSBL operators are content to operate in the dark, and refuse to communicate, what makes you think they will pay attention to a BCP? (*) Fortunately in most cases it was people asking me for help with Linux, so I simply found another way to send the e-mail, and then sent them a note saying that until they switched ISP's or fixed their mail server to remove the use of the DNSBL, I would refuse to help them with their Linux ext3 problem. :-) But I view DNSBL's as fundamentally the Wrong Answer, and it breaks the intended SMTP and Internet architecture, with fundamentally wrong power dynamics. Of course, if you run a major mail operation, where DNSBL's don't dare block you lest it become obvious that the whole mechanism is corrupt, you don't see these problems. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-irtf-asrg-dnsbl (DNS Blacklists and Whitelists)
On Sat, Nov 08, 2008 at 05:41:41PM -0500, Keith Moore wrote: I really think that if you can design and standardize a protocol for reporting reputation which includes a mechanism for making the reputation service accountable to end users, and also is reasonably secure, you might seriously improve email reliability. I just don't think that DNSBL is good enough for that and I doubt that DNS can be stretched far enough to make that work well. Indeed; reputation system for the reputation servers! Of course, if DNSBL operaters were to find the that shoe was on the other foot, such that their reputations were getting judged by the same criteria that sites are declared unclean (i.e., by unauthenticated rumor), maybe there would be more attention and care towards some secure, accountable way for conclusions to be reached on some particular host's reputations, whether it is running a SMTP server or a DNSBL, and for a more secure, authenticated, and accountable way for that reputation to be carried across the network. - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Chrome and NoteWell?
On Wed, Sep 03, 2008 at 04:59:04PM -0700, TS Glassey wrote: Folks does the Chrome EULA prevent anyone using it from participating in the IETF? Just a thought. Google has already backed down from the EULA. And as Ars Technica as pointed out[1]: It's worth noting that the EULA is largely unenforceable because the source code of Chrome is distributed under an open license. Users could simply download the source code, compile it themselves, and use it without having to agree to Google's EULA. The terms of the BSD license under which the source code is distributed are highly permissive and impose virtually no conditions or requirements on end users. [1] http://arstechnica.com/news.ars/post/20080903-google-on-chrome-eula-controversy-our-bad-well-change-it.html - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for review of proposed update to ID-Checklist
On Tue, Jul 08, 2008 at 02:27:41PM -0500, Pete Resnick wrote: The document says: If ABNF is used, you MUST include a normative reference to RFC 4234. To quote two fine radio personalities here in the states, this one seems boogus. Yes, any I-D that uses ABNF must include a normative reference to RFC 4234, but for the IESG to not engage in review until it is in there is silly beyond belief. Make a note to the author that they need the reference and continue consideration. Stupid question isn't this specific thing something we should allow the secretariat to fix as part of the RFC publishing process, and in fact give them instructions to add the reference if they find it missing? They do things like fix/update references IIRC, and this is only a minor step beyond that, and should be well within their capabilities, I would think. Sure, we can ask document editors to add the reference to RFC 4234, and maybe we can even do things like include a reference to RFC 4234 in an RFC template file with a note to remove if the standard ends up not using ABNF, but there must be a class of things which could be streamlined to save time on both the document editors, reviewers, and AD's time. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms % ping hk. PING hk (203.119.2.28) 56(84) bytes of data. 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=1 ttl=238 time=265 ms 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=2 ttl=238 time=265 ms Not very reliably, I think. :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 02:13:47PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 05:01:30PM -0400, Theodore Tso wrote: On Mon, Jul 07, 2008 at 01:38:28PM -0700, Ted Faber wrote: On Mon, Jul 07, 2008 at 01:32:10PM -0700, [EMAIL PROTECTED] wrote: If you can cite verifiable evidence that even a single case that works reliably now, will cease to work, I'll concede that there is at least a hint of merit to your argument. e.g. an actual email address or URL that uses a single-label domain name. zod:~$ ping hk PING hk (203.119.2.28): 56 data bytes 64 bytes from 203.119.2.28: icmp_seq=0 ttl=243 time=183.582 ms % ping hk. PING hk (203.119.2.28) 56(84) bytes of data. 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=1 ttl=238 time=265 ms 64 bytes from www.hkdnr.hk (203.119.2.28): icmp_seq=2 ttl=238 time=265 ms Not very reliably, I think. :-) Sorry, I cut and paste the wrong example. What I had meant to cut and paste: 5% ping hk PING hk.ibm.com (9.190.250.244) 56(84) bytes of data. ... - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Update of RFC 2606 based on the recent ICANN changes ?
On Mon, Jul 07, 2008 at 03:56:10PM -0600, Willie Gillespie wrote: With your hk.ibm.com example, do you have any search lines in your /etc/resolv.conf file that would be automatically appending? Of course! That was my point about why http://hk; or ping hk is not going to be terribly reliable. If you think people are going to type http://hk.;, I can probably come up with Web 2.0 startup that you could fund, if you're not interested in purchasing a certain bridge in New York City... :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Blue sheet harvest
On Fri, Apr 04, 2008 at 11:50:08AM -0700, Bill Manning wrote: On Fri, Apr 04, 2008 at 07:08:41AM -0400, Scott O. Bradner wrote: it started w/ folsk scanning the pages of the early bound copies of IETFF proceedings. the sheets are no longer included in the proceedings right - the point is that this has been a problem for years. How is this a problem if the pages are no longer being included? Do people seriously think (or fear) they are are getting scanned in the room? Or the Secretariat is scanning them and selling them to list brokers to fund the cookies and soda? :-) It seems almost as if this is more of a perception problem than one where there is an actual issue with e-mails going to spammers given the current arrangement. - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-klensin-rfc2821bis
On Sat, Mar 29, 2008 at 10:16:10AM -0400, Keith Moore wrote: I think it is time to put an end to specious arguments. These standards get used for decades. I don't think it's appropriate to cripple them because of some arrangement that happens to exist now from a few dysfunctional DNS providers. Providers will get more flexible as the need becomes apparent, and domain owners who have problems with their DNS providers can change providers. It's not difficult. So I must be missing something, probably because I deleted without reading closely enough one of the earlier messages on this thread. But please indulge me --- exactly what is the benefit of deprecating the A fallback, and/or not doing a lookup on the record if the MX record doesn't exist? Is it the load on the nameservers that people would believe would be reduced if we didn't do this? Is that really a problem? Or is it something else? - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
On Tue, Mar 25, 2008 at 08:53:15AM +0100, Stephane Bortzmeyer wrote: On Tue, Mar 25, 2008 at 05:08:31AM +0100, Harald Tveit Alvestrand [EMAIL PROTECTED] wrote a message of 28 lines which said: we had this exact problem with the many identities of Jeff Williams; he had enough pseudo-personalities on the list that he would sometimes claim to have a majority, jut from his own postings. Since IETF does not vote, it is certainly not an issue here? Well, it can be an issue in terms of determining rough consensus. Suppose you have 100 sock puppets all with gmail or hotmail accounts, all claiming that some approach which all of the key technologists and experts in the field and RFC authors have rejected, is really the right way to go. We can do straw polls in face to face meetings, but in theory, all decisions are supposed to be confirmed on the mailing list. Suppose 100 (presumed) sock puppets who all just happen to have the same fracturered logic and writing styles as JFC show up on LTRU and claim that they are driving consensus. RFC 3683 evasion aside, it could certainly cause cause problems for a working group chair who is trying to determine consensus, such that said chair might want to confirm whether or not 100 posters to the mailing list, all with pseudonyms derived from the name of of French pioneers/heros, were in fact distinct people. After all, they could all argue that the nonsense they are spouting is in fact deep received wisdom, and it's a minority of the working group who don't understand their reasoning, and so therefore the positions of their Great Leader JFC, is in fact rough consensus. :-) - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
On Tue, Mar 25, 2008 at 09:40:38AM -0500, Spencer Dawkins wrote: As Ted said, in theory, all decisions are supposed to be confirmed on the mailing list, but I haven't seen anyone point out the reason why - because we also think it's important to have very few barriers to participation in the IETF, so we don't require attendance at any face-to-face meeting, ever. So I'm not sure how we verify identities when anyone we question can just post from an e-mail account at an ISP in Tierra del Fuego, and say the next time you're in the tip of South America, come by and verify my identity. Well, usually someone who says, I think you should do foo, follows it up with, because of bar, and while the alternate choice has upside quux, I believe the engineering tradeoff is such that bar is far more important than quux. So usually it doesn't matter whether someone is posting from Sunnyvale or McMurdo Station. So often, in practice, it doesn't matter. So I think I would certainly grant your argument that most of the time it doesn't matter, which is probably why we haven't spent a lot of time trying to come up with detailed procedures for how to deal with the situation. I certainly think an ad hoc approach such as what the LTRU wg co-chairs chose, with consultation with their AD, was the right way to go, and if LB, whoever he is, wants to challenge their procedure, let him go up the appeal chain. The IETF is still a meritocracy, not a democracy. Bad ideas are still bad ideas, even if lots of people have them. Binary numbering still uses two values (zero and one), no matter how many drafts say something else. Working group chairs have two responsibilities - to be fair, and to make progress. When these responsibilities collide, it's not going to be pretty, but Russ's point - we actually do know how to resolve conflicts in the IETF - is critical, because the alternative is that work just stops. Sometimes we just need to make a decision and move on. If you were right, but couldn't convince the WG chair(s), AD, IESG or IAB that you were right, and couldn't convince enough people to sign a recall petition - well, next time, do a better job of convincing convincing people. No argument here. In fact, I'd argue that the justification *for* PR actions is to make progress, when someone who doesn't understand that they've lost a particular battle by not being a part of the rough consensus can't let ago, and move on - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
On Tue, Mar 25, 2008 at 05:12:33PM +0100, Simon Josefsson wrote: Frankly, it strikes me as somewhat odd that a body acting as a standards-setting organization with public impact might allow any technical decision on its specifications to be driven by people operating under a cloak of anonymity. Expressing an anonymous voice? No problem. Influencing determination of a consensus with public impact? That should not be allowed, IMO. What if the pseudonymous voice raise a valid technical concern, provide useful text for a specification, or even co-author a specification? I think decisions should be based on technically sound arguments. Whether someone wants to reveal their real identity is not necessarily correlated to the same person providing useful contributions. A valid technical concern is easy to deal with. If they provide an idea, I suspect a cautious working group chair might insist on knowing their real name and company affiliation, since there have been past examples where companies have tried to inject patented technologies into a standards specification. (For example, see the FTC's decision re: Rambus[1].) [1] http://www.law.com/jsp/article.jsp?id=1161606920964 If someone is providing text or co-authoring a specification, there are once again copyright considerations which could cause the IETF much headaches. If a Cisco employee were to provide text, and then suddenly yank back copyright permission and disclaim the Note Well, their are consequences to the engineer and to his/her employer if they were to do so. A contributor operating under the cloak of anonymity can evade many of the consequences of being a bad actor. Which once again brings us back to the question of what is the value of letting contributors operate under a cloak of anonymity, and do the benefits outweigh the costs. For political speech where someone wants to distribute the equivalent of leaflets decrying their current's government position on say, torture in violation of the Geneva convention, it's much easier to make the case that allowing anonymous speech is hugely important. In a standards organization, it's much harder to make the argument that anonymity is really a benefit. For example, in the current MS-OOXML controversy, anonymity would make it impossible, or at least much more difficult, to determine whether or not Microsoft really did pack various countries' national bodies with their business partners, and reimbursed membership fees via marketing considerations. So I'm rather glad that all or most ISO national body rules do require declaration and disclosure of legal names and corporate affiliations. - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Possible RFC 3683 PR-action
On Tue, Mar 25, 2008 at 02:23:42PM -0400, Edward Lewis wrote: I do cringe when anyone says not wearing any hats - especially when I don't know what hat they might be wearing at any given time. I know it's a time-honed (not honored) tradition in the IETF but I don't think it's a good thing. Taking off hats, that is. When I've used that phrase, it's almost always meant not wearning any IETF hats. That is, this is my own personal opinion, to be reviewed on its own merits, and not based on any role-based authority I might have as document editor or working group chair to determine consensus. I've most commonly heard it from Area Directors, who want to make it clear that this is their own personal preference, and not something which should be interpreted by the working group as, Make this change or when it comes up before the IESG I'll vote DISCUSS and your standard will never progress! Bwa-hah-hah-hah! :-) Of course, very often an AD is very much an technical expert, and their opinion will carry much more weight than someone random that no one knows. And most AD's would never try to impose their will using the DISCUSS blunt instrument unless there's something very badly wrong. But sometimes folks are too easily over-awed by titles, so it can be useful for people to reinforce that he's disclaiming any role-based authority when making a comment. Regards, - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Ltru] Possible RFC 3683 PR-action
On Sun, Mar 23, 2008 at 08:45:19AM -0700, Christian Huitema wrote: Does the IETF have a policy regarding misrepresented identities? In the particular incident, it is assumed that the person using the name of a famous French aviation pioneer is in fact someone else. On the one hand, using pseudonyms is a form of free speech. But on the other hand, in a standard setting body, hiding identities is not necessarily something we want to encourage. What are the implications for our standard process? What about copyrights and patents? The use of pseudonums is very much a form of free speach. To quote from from the U.S. Supreme Court, `Anonymous pamphlets, leaflets, brochures and even books have played an important role in the progress of mankind.’ Talley v. California (1960). Great works of literature have frequently been produced by authors writing under assumed names. Despite readers’ curiosity and the public’s interest in identifying the creator of a work of art, an author generally is free to decide whether or not to disclose her true identity. The decision in favor of anonymity may be motivated by fear of economic or official retaliation, by concern about social ostracism, or merely by a desire to preserve as much of one’s privacy as possible. Whatever the motivation may be, at least in the field of literary endeavor, the interest in having anonymous works enter the marketplace of ideas unquestionably outweighs any public interest in requiring disclosure as a condition of entry. Accordingly, an author’s decision to remain anonymous, like other decisions concerning omissions or additions to the content of a publication, is an aspect of freedom of speech protected by the First Amendment. --- McIntyre v. Ohio Elections Commission, 1995. However, free speech rights are those which a government is not allowed to abograte via the unique coercive means made available to it (i.e., prison, fines, etc.). Free speech does not imply that anyone wishing to avail themselves of their free speech rights gets to use anyone's printing press or radio station or television station or IETF wg mailing list to broadcast their free speech to the those that have no interest in listening to it. Nor does it give people the right to use a bullhorn to loudly blare their opinions in a residential neighborhood at 3am in the morning. So free speech rights is a red herring, in terms of whether or not any decision made by the IETF would violate LB's fundamental human rights (assming he really is in the EU), since the IETF is not a state actor, and he is perfectly free to spout his views about the multilingual internet in plenty of other fora. In terms of whether or not there is value added by allowing anonymous contributions in IETF wg mailing lists, issues arround copyright and the IETF's patent disclosure rules seem to mitigate any posible value in a standards context, and while I wouldn't suggest making a big deal of requiring identity verification for every single working group participant, if there is reasonable cause for a working group chair to believe that someone is using a pseudonym to evade an RFC 3683 PR action, that the IETF reasonable proof of a real-life identity. Certainly some of the claims made by LB of this being done with the support of our two direct commercial competitors in his WG can not be evaluated while LB tries to hide behind a shield of anonymity. - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom process realities of confidentiality
On Thu, Mar 20, 2008 at 02:06:12AM -0400, Noel Chiappa wrote: On Wed, Mar 19, 2008 at 10:11:09AM -0700, Dave Crocker wrote: ... the conduct of Nomcom processes tends towards pretty classic personnel assessment, but with people typically lacking classic personnel training or experience. This would be different from a normal election... how? :-) Well, one of the that have been raised in the past about keeping the list of candidates confidential, and to have Nomcom ask send out questionnaires to a specific, targetted set of more senior technical leaders in the community, as opposed to simply throwing it open and having everyone send in comments, is (a) it might overwhelm the Nomcom who might have to wade through a vast number of comments, and (b) it might turn it more into a popularity contest, as opposed to picking someone who was the best qualified. But as I said earlier, this is one of the places where how you frame the NOMCOM process is critical. Is it a governance process, where we are trying to select the organizations political leadership, in which case perhaps direct elections and campaigning and complete and total transparency, with no privacy rights expected or given (maybe we should demand that candidates publish their tax returns, like US Presidential candidates :-)? While we're at it, maybe we can take snippets of comments made at an IETF plenary years ago, take it out of context, put it on You Tube, and arrange to have it played constantly and constantly on the evening news Or is it a personnel process, where we are trying to find the best candidates to promote to a technical architect position --- and in personnel processes there is usually *much* more use of confidential feedback and information, and most of the time, when the management selects who will be the next senior technical architect for a department, the junior engineers just out of college don't get to see the list of candidates being considered, and get to submit comments to the promotion board about whether it's easier to work with candidate A or candidate B. The answer of course, is that it's a bit of both. Which leads to all of these tensions, and IMHO one of the reasons why we have such a hard time finding consensus on this issue. Regards, - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: fyi: Paper: State of the Internet Challenges ahead
On Fri, Mar 21, 2008 at 09:45:53AM +1300, Brian E Carpenter wrote: Well, try reading it before you rush to judgement. I've always found Olivier's opinions well worth listening too. I tried reading it, but it is much more descriptive than perscriptive, and in many places I didn't find a rationale to back up his opinions. He also borrows a lot of material from many places, and while the web pages are clearly marked in footnotes, in some cases it appears that he does so without bringing in the context. For example, he has a diagram, Areas of Internet Governance which includes in one of six clouds, Illegal Activity: fraud, theft, child pornography, gambling, trafficking, stalking, etc.. Now, I don't normally associate that (alongside Regulation, Legal Activity, Standards, Operations, and Applications) as areas of Internet Governance and he doesn't explain the meaning or the point he was trying to make with that document. As a result, I tried very hard to see what point he was trying to make (and I reread the document based on your recommendations of his opinions), but it was very hard not to dismiss him as a crank. Perhaps a crank that had clearly mastered the game of buzzword bingo, and with a clear bias towards circuit-switched networks with bandwidth reservation as being far better than what the Internet currently uses, which he calls ossifying and degenerate, but I didn't see any suggestions for how to make things better, even according to his valuation criteria of what is good or degenerate. - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Nomcom process realities of confidentiality
On Wed, Mar 19, 2008 at 10:11:09AM -0700, Dave Crocker wrote: Add to this the fact that a) we have no detailed rules for confidentiality but rather treat the word as having implicit-but-total effect on behavior, b) we have no enforcement powers over violations, and c) Nomcom members, IAB members, IESG members and ISOC members typically do not have any background in maintaining confidentialities of these types. (On item c), if you think that there is no need for training or experience, please think again. Organization personnel matters are peculiar processes.) ... The concept of Nomcom was a creative solution to the challenge of making formal community decisions in the absence of formal community membership. That said, the conduct of Nomcom processes tends towards pretty classic personnel assessment, but with people typically lacking classic personnel training or experience. Coupled with a lack of institutional specification for the construct or enforcement against violations and we are certain to get distorted processes. What if we simply made the Nomcom access to training materials about these matters? I'll a number of IETF'ers, as senior technical personnel, probably have at least some management responsibilities in their day jobs or in the background, and for those that don't... well, when I first joined my Church Vestry, I got a handbook on Church Business Practices for new Vestry Members; when I first joined the Usenix board, I got a handbook on what new Board Members for Non-profit members needed to know and understand --- which I didn't need, since I had already gotten a similar handbook when I was appointed to the Episcopal Diocese of Massachusetts Diocesan Council. The business issues that are needed for a board member (how to read financial reports, issues of fiduciary duty, etc., aren't stuff that you would expect everyone to know, but it's not *that* hard to learn them). Similarly, it's not that hard to learn about personnel issues. (Not that I got any training when I had my first management responsibility at MIT; I had to learn things the hard way. IBM has a better and more structured training program for new managers and new executives. And now that I am on assignment at the Linux Foundation, and I am functioning in a managerial function, I knew enough to reach out and to get some training to refresh my long-rusty managerial skills.) OK, so knowing how to do a fair performance evaluation isn't something we should assume a random programmer or network architect to have under their belt. But it's not that *hard* either. And in companies, there are reasons why personnel evaluations are kept confidential and not released to the entire department after the 1st line and 2nd line managers do the annual employee performance reviews and results of discussions around who should get a particular promotion. Just because the Nomcom doesn't have training, doesn't mean that the right answer is to throw accumulated wisdom and experience of how do proper personnel procedures out the window, and make all discussions public. If that means we need to have an organizational consultant give a 2 hour training course to each year's NOMCOM about how do their jobs in a fairer way, I would think that is a much better solution than just throwing confidentialty complete out the window. Regards, - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confirming vs. second-guessing
On Mon, Mar 17, 2008 at 11:38:20PM -0700, Fred Baker wrote: It sounds like you would rather get rid of the nomcom and have the confirming body do the work from the start. It's interesting to note that this would mean reverting our processes back to the pre-1993 days, back when the IAB *did* pick the IESG. One of the reasons why the Nomcom was created, way back then, was because of the July 4, 1992 fireworks (as I believe Vint Cerf termed them) on the IETF list. I've also heard it referred to as the Boston Tea Party of the IETF. To quote from Christian Huitema's, Network Protocols and Standards as to what happened: We thought that our wording was very careful, and we were prepared to discuss it and try to convince the Internet community. Then, everything accelerated. Some journalists got the news, an announcement was hastily written, and many members of the community felt betrayed. They perceived that we were selling the Internet to the ISO and that headquarters was simply giving the field to an enemy that they had fought for many years and eventually vanquished. The IAB had no right to make such a decision alone. Besides, CLNP was a pale imitation of IP. It had been designed 10 years before, and the market had failed to pick it up for all those years. Why should we try to resurrect it? The IAB announcement was followed by a tremendous hubbub in the Internet's electronic lists. The IAB draft was formally withdrawn a few weeks later, during the July 1992 meeting of the Internet Engineering Task Force (IETF). The incident triggered a serious reorganization of the whole IETF decision process, revising the role of managing bodies such as the Internet Engineering Steering Group (IESG) or the Internet Architecture Board, the new appellation of the IAB. At the time, there was a feeling that the IAB was out of touch, and that the Nomcom selection process was a better way of getting community consensus about the engineering leadership than the previous scheme where the IAB was a self-perpetuating body which selected the IESG. For a long time, given how hard the IAB had been slapped down, it pretty much let the Nomcom do most of the work, and when I submitted the 2001-2002 Nomcom report to the confirming bodies, what we provided was a brief resume and a short testament summarizing the deliberations and reasoning behind the choice (in most cases it was a paragraph or two). At least for the years when I was on Nomcom, the IAB did not request access to any of the questionaires or comments from the community; all we provided was 2-3 paragraphs describing some of the concerns and summarizing at a high level what the concerns which drove us to replace an incumbent and why we chose a particular new AD. It seems that since then, the IAB has been more assertive about wanting more information, and I really think we need to consider where the line is between performing due diligence and redoing the work of the NOMCOM. I personally like the line that we drew in the early 2000's; we told the confirming bodies the issues about why IESG or IAB members were not returned to the body, and why we picked new members. The confirming bodies asked us if we had considered certain issues, and we had to draft a response when went into more detail, but that was about it. I have heard it said that the IETF, in the most recent discussion that failed up update that portion of what we now call 3777, had a 90/10 consensus and didn't come to a perfect consensus. I think we have to say what the role and reach of the confirming body is, which may require us to think hard about what it means to have rough consensus. I'm not sure it was 90/10 consensus; at least in this recent discussion, there certainly have been a rather wide range of opinions on this list, from people like Mike St. John's with one view, and Steve Kent with another. - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confirming vs. second-guessing
On Tue, Mar 18, 2008 at 08:24:39AM -0700, Dave Crocker wrote: This wasn't about careful wording or reporters getting ahold of the story. This was about a premature and preemptive decision by the IAB. I quoted Christian's story because it was the kindest towards the IAB. There were of course far uglier spins on the IAB that were running around, and the truth is somewhere between the two, I think. It's not really that important. I quoted it becuase I thought it might be useful to consider the history around the creation of the Nomcom. A phrase like serious reorganization leads folk to miss how small the changes were, structurally. The existing structure of the IETF was retained. From the standpoint of organization structure, the changes were minimal, although of course they had huge impact. There were only two changes: 1. Decisions previously made by the IAB would now be made by the IESG 2. A formal and independent selection process for the IAB and IESG would be instituted. The IAB was retained but careful to avoid anything that looked like an attempt to exercise power. Over time, if found very useful tasks for itself. We can dispute how small the changes actually were, but the key point was that IAB had nearly all of its power stripped from it, aside from the power to make recommendations and, and that was moved to the IESG. That was a pretty earth-shaking change to the power hierarchy, even if it was only executed using a few small changes. (As we all know, changing even a few lines of code can make a huge difference in how a program functions.) I suspect, but am not 100% sure, that the very early NOMCOM's, in 1993-1996, probably had their decisions close to rubber-stamped, given how badly the IAB had been slapped down by the events of the July, 1992. Eight years later, right after the turn of the century, it seemed they were exerting themselves more (and I think that was appropriate), and it seems to me that more recently, the pendulum has swung even further to the right. So perhaps it's not surprising that we're all over the map, since if you look at past practice over time we've been all over the map as well. The question, today, seems to be whether it is moving too far into an exercise of powers it ought not to have. This isn't anything like the Boston Tea Party situation -- the organizational change was made at the IETF in Danville, whereas the offending decision was made in Kobe Japan -- since it is incremental and is clearly being reviewed as things change. I agree that it's nothing like what happened in July, 1992, and we *are* having this discussion. The question indeed is what is the right level of powers is most appropriate for the IAB; ranging from nearly all powers stripped from it in 1993, to now where it is requesting access to substantially more documents than it had historically, and where a few are aruging that the trust boundary for the Nomcom and the confirming bodies should be the same (i.e., that the confirming bodies get to see all or nearly all of what the Nomcom gets to see.) Right. The current discussion should try to specify what exactly the boundaries and requirements for a confirming body are and what input is reasonable for them to have. And furthermore, give more clarifications about when a confirming body should try to act. I believe, for example, that if a confirming body were to say, yes, we believe that Person A would do an adequate job, but Person B will do the job 10% better, and we will reject the slate until you select person B, that this would be an abuse of the confirming body's powers. If instead the feedback is, we believe this person is totally unqualified, or if you select this person half of the volunteer IETF members in the area will walk off in a huff, that's a very different, and appropriate feedback from the confirming body. In between these two areas, of couse, is a rather large grey area... - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Confirming vs. second-guessing
On Tue, Mar 18, 2008 at 02:08:15AM +, Steven M. Bellovin wrote: Try this one, quite non-hypothetical: a candidate for the IESG is contemplating switching jobs. His or her current employer does not yet know this. It has a clear bearing on whether or not that person can do the job of AD, but equally clearly should not be broadcast to the world. A lot of whether you think information shared with NOMCOM should be confidential depends on whether you frame the process from the point of view of a governance issue, or from the point of view of personnel process. I think most poeple would agree that if you consider Nomcom as being more of a performance review or a hiring/firing process, then like most personnel issues, the information used to make these sorts of decisions should be treated as confidential. Certainly if I give feedback about my manager or vice president as part of some 360 review process, I would feel *quite* betrayed if that information was shared any further than it needed to be, lest that information get back to the person in question --- or to a close friend of the person in question. If you think of NOMCOM as being more of a governance question, then especially if you are from the United States, and in particular from those localities that have Open Meeting or Open Door laws that mandate complete transparency in governance where *all* meetings between any 2-3 goverment officials must be adequately noticed so the public can attend and minutes taken which are publically posted, then you'll probably also share the opinion that NOMCOM should run without any confidentiality at all. (As an aside, I've noticed that this is not true in all cultures, and there is variance on this depending on where you're from. I've been on committees where we debated this issue, and I recall some Europeans saying at this absolute insistance on complete transparency was quite daft --- their words --- and not the norm from their experience.) The problem is that NOMCOM process can be viewed through either lens equally well, and I suspect that's one of the reasons we don't have consensus on this issue. My personal bias, as a former NOMCOM chair, is to view NOMCOM as being more of a personnel process, and thus I believe that most information about the process should be kept confidential, *especially* if making it public were might dissuade some talented individuals from throwing their hat in the ring. As for the related issue concerning the role of the confirming body, I personally believe that the confirming body should act more as a *sanity check* than anything else. That is, it should question any obvious process violations that it noticed or had brought to its attention (perhaps through the Laison) and if some choice has some obvious problems that might harm the IETF if said selection should go forward, the confirming body should ask questions. However, if there are two obvious, viable candidates, and the choice of one or the other is a 60/40 or a 55/45 question, I do **not** believe it is the place of the confirming body to request so much information so they can second-guess the NOMCOM and determine whether they made that 60/40 or 45/55 call correctly. This is more than rubber-stamp, in that the confirming body should call into question obvious mistakes in the result or process (or what might be appear to obvious mistakes). But there is a far cry between that and guaranteeing that the NOMCOM made the correct decision. In order to do the latter the confirming body would need a lot more information and effective redo the work of the NOMCOM in order to effectively check their sums; and I don't believe that is a healthy or useful use of the confirming body's time. However, I don't believe (although I would be delighted if I was wrong) that we have consensus on this point, either... - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: EAP applicability (Was: Re: IETF Last Call on Walled Garden Standard for the Internet)
On Thu, Mar 13, 2008 at 09:47:31PM -0700, Lakshminath Dondeti wrote: Let us consider the opposite situation. Let us say the hotel network uses EAP for authentication and the hotel front desk gives the IETF folks a scratch card with credentials. We then use the credentials for authentication using 802.1X-EAP (example only). The hotel or an associated third party also offers some services/applications and wants to provide them for free for the IETF folks. However the hotel does not want to share the credentials with the third party server. Sure, the hotel may not make this facility of key management for all application providers out there and this mechanism is not useful for general purpose application access. Why would we force the hotel to provide multiple sets of credentials for each additional service/application that they want to provide? OK, let's take this example as a thought experiment. Where are the applications going to come from? In general, getting application vendors to ship clients which implement any kind of security code has been like pulling teeth. We've been mildly successful with TLS/SSL and in certain very specific cases (i.e., https and mail applications). Something esoteric that only works on networks that happen to provide EAP keying will be such a small part of the market that getting wide availability such applications is going to be, um, difficult. So that basically means that the hotel is going to have to provide the applications which use this hotel-specific service. Training users that, no really, it's OK to download applications from random hotels and installing it on their corporate laptops is something which I'm *sure* the I/T departments will treat with special joy --- and by joy, I mean fear and loathing. :-) Certainly from a corporate perspective, applications which can't work on home networks (that may not use EAP at all, or in any case, if they have EAP, are coming from an untrusted home Linksys/D-Link/whatever router), is going to be at all interesting. And from a security perspective, would certainly violate the end-to-end principle. So aside from applications which are very much tied to the local network --- i.e., network access protocols, maybe as a way of securing a response from a dhcp server, etc. --- I'm not sure for which applications an EAP based key would make any sense at all. - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Was it foreseen that the Internet might handle 242 Gbps of traffic for Oprah's Book Club webinars?
On Sat, Mar 08, 2008 at 11:36:28AM -0500, Marshall Eubanks wrote: I have to wonder, though, if any ISP will have the guts to block Oprah. Heh. and if they tried, I'm just imagining what would happen when she tells all of her faithful audience to call up their congresscritters to support Net Neutrality :-) - Ted ___ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 NAT?
On Mon, Feb 18, 2008 at 03:34:50PM -0800, Hallam-Baker, Phillip wrote: In the scenario I gave, the data I wish to stop the kids accessing is already on my network, net nanny is totally useless in this instance. Let us imagine that I have a configuration that consists of one Vista machine and one Home Server on which there is stored a collection of ripped DVDs of video nasties, you know The Sound of Music, Care Bears Movie etc. some of the nastiest films I have seen. I do not with the kids tastes to be corrupted by this rubbish. Heh. From the Capitol Step's, All I Want For Christmas Is A Tax Increase album: http://www.amazon.com/gp/music/wma-pop-up/B03JOO001001/ref=mu_sam_wma_001_001 Security cannot be effective when it is provided in the form of a DIY assembly required project. But thats what the field has been doing. I'm afraid it's worse than that. As long as we provide general purpose computers, and some insiders that are determined to bring home databases filled with SSN so they can do work in the evenings, or children who know more about computers than their parents and who are determined download videos of Barney does Dallas, I'd claim is pretty much impossible to solve the particular security problem which you are worried about. And I'm not sure people are really willing to accept computers with the sorts of controls that would prevent these sorts of attacks on data. Look at the resistence to Microsoft's Palladium project by people such as Ross Anderson. (http://www.cl.cam.ac.uk/%7Erja14/tcpa-faq.html) Most consumers are far more focused on the sorts of abuse that could be perpetrated by Hollywood, the Music Industry, and Microsoft, rather than problems with databases filled with US Military personnel's credit information getting stolen out of unsecured laptops of incompentent government bureaucrats. One could have a debate about whether this is a correct assessment of risks by the consumer and by organizations like EFF and EPIC, but it's reality that won't be easily changed. In any case, this is a bit of a rathole from the original discussion, I suspect - Ted ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
On Fri, Feb 08, 2008 at 04:00:26PM -0500, David Harrington wrote: I think the complaints would simply be slurred more, and we might have to worry about lynch mobs (which would remind me of the reasonableness of this discussion so far). To be fair, I think most of the concerns raised on this discussion have been relatively reasonable, although perhaps people have been worrying without having enough information. It appears that they may be some restaurants other than those in the hotel; whether they are sufficient is unclear at the moment, but either way, the die is seems to be cast and even if there are not sufficient restaurants, it seems too late to do anything about it. (Except maybe for adjusting the schedule so people have time to take the buses into Dublin, or some such, if it really is an issue.) One sugestion that I would make for the people who are tasked to do site surveys is to collect a list of resturants nearby, with addresses, type of cuisine, average cost for lunch/dinner, distance from the hotel, and number of diners they can handle. I suspect the concierge for the conference hotel has the information on hand already, so collecting it shouldn't be difficult; just asking them to make the information available should be all that's needed. Placing this information on the web site would be extremely useful for IETF attendees who are trying to determine where they can get sustenance without mobbing the concierge, and it would also serve to ease the minds of people who might have various dietary restrictions, or just want to make sure that there are alternatives beyond buying lunchmeat at a local convenience store or paying $24 for a coffee and a pastry at an expensive resort restaurant. (I've paid that much in Venice when on vacation; never again...) - Ted ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 -- Dublin!
On Wed, Feb 06, 2008 at 01:29:40PM -0500, Edward Lewis wrote: I really have a hard time being sympathetic to this complaint. If the purpose of the IETF is open discussion and cross-pollination, what does it matter where we are so long as there's comfortable access to the expertise needed? Is there an unwritten requirement that IETFs are placed to afford us sightseeing? To afford us access to restaurants? Well, many IETF'ers get tired of eating at the same hotel restaurant, day after day, for the whole week. Also a common problem is that many hotel restaurants are not well equipped to deal with a very large number of people all showing up at the resturant at the same time (+/- 10 minutes), thus flooding the kitchen with orders and resulting in glacial service times. I remember one of the first times we were at Minneapolis, and I made a mistake of eating at the hotel restaurant for lunch, and the food not showing up at the table until something like 5 or 10 minutes before the next working group meeting was supposed to start. Needless to say, that was the last time I frequented that hotel restaurant the whole week! Fortunately in Minneapolis there were other restaurant options that were a close walk away from the hotel. I am a regular attendee at many other conference series. Although some series face greater logistical challenges (like venues cancelling late in the planning, under powered metro and hotel infrastructures, etc.) and pose less convenient travel arrangements for the average attendee (using places off the main grid), I hear much less whining from the attendees there than I hear about IETF arrangements. The IETF is somewhat unique in that it is a fairly large event that still has fixed meeting slots so that everyone shows up for lunch at roughly the same time. That's not so much the case at a trade show, for example, and many conferences are smaller. But basic issues such as access to restaurants and the ability to serve N hundred people in a short period of time are important for anyone who does meeting planning. There are other solutions, such as buffet service, but it is an issue. Yet another questioned the distance from outside restaurants[1] - apparently many fine lunches and dinners is required, exercise is immoral. Heh. I consider myself a fairly serious foodie[1], but most of the time when I go to conferences and meetings, especially at lunch time, it's usually a food court style restaurant that I'll frequent, because it's (a) fast, and (b) convenient. Besides, there really isn't time for a proper 12 course tasting menu if you want to get back in time for the evening meetings or BOF's. :-) But what's really, really, annoying for me is if the only restaurant around is a super expensive restaurant at an hotel, where service is slow and you end up being late to the after-lunch or evening working group meetings as a result. Being at a resort hotel often adds insult to injury, because (a) the food is priced comparable to food served at Aquavit or the French Laundry, but (b) the quality of the food is cr*p and certainly not worth the $$$ that you spend *because* it is at a resort location. For me, I'll take business-class hotel like a Hilton or a Doubletree any day and even better if it is adjacent to a mall with a food court. When I go to an conference or a standards meeting, it's to get work done, not to do fine dining or lounge at a resort setting. And if I'm going to pay $$$ for an expensive restaurant, I want to get my money's worth, which is rarely the case at most hotel restaurants. - Ted [1] http://thunk.org/tytso/blog/2007/10/08/sous-vide-revisited/ ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Transitioning the IETF web site and email services
On Mon, Jan 14, 2008 at 07:51:58AM -0800, TS Glassey wrote: What are the retention requirements here Ray and what are the availability requirements per the Stored Communications Act is the US and has this transition ever been scoped out against these constraints? or is it the IETF's intent to ignore US Law again? Todd, If there is something you think that needs to be done to be in compliance for some particular US Law, it would be helpful if you stated exactly what it is you think needs to be done and reference the specific US Code, Section, and Subsection in question. The Stored Communication Act (Title 18, Part 1, Chapter 121, Section 2701) seems to only apply to ISP's providing IMAP/POP e-mail service to the public (i.e., any paying user who is a customer), and so it's not at all clear it even applies to the IETF, since the IETF isn't in that business. Furthermore, the only record retention requirements that I can find only seems to apply if a government entity makes a request of the ISP for up to 90 days pending the issuance of a court order, so even if it *did* apply, there doesn't seem to be anything the secretariat needs to do. Presumably the IETF Secretariat will contact its legal resources whenever there is some situation (possible lawsuit, request by a government entity) where data retention may be required. In any case, I and (as far as I know) Todd are not lawyers, so none of this constitutes legal advice. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Sgt at Arms Please? RE: TLS-authz experimental standard
On Mon, Jan 14, 2008 at 10:27:02AM -0800, Hallam-Baker, Phillip wrote: The FSF copntinues to attempt to re-open this decision. I don't see any infomation content to these posts, beyond the already known facts that 1) RMS has people read his Web site and 2) perpetrates a one-way form of communication - we have to listen to him but he has no intention of listening to us. I suggest that we consider a mechanism for sending any message that is CC'd to [EMAIL PROTECTED] straight to the bit bucket. The fact that it is multiple individuals responding to an obsolete campaign page rather than one noise maker does not make it any less disruptive. Actually, to be fair, I don't think this can be laid at the feet of the FSF. Todd Glassey replied to a message approximately 3 months old with some legal reasoning that at best seems highly contorted, and at worst total nonsense. (For example, requirements for a claim of tortious interference of prospective economic advantage, or TIPA, are quite specific, and almost certainly don't apply; people who are interested are invited to google the term for themselves, and/or pay a lawyer for a legal opinion). Whether they are or are not, Todd's legal thoughts make sense, *discussion* of these sorts of legal matters are outside the bounds of the IETF. Applying law to facts requires a law degree to in order to give legal advice and form a formal legal opinion, and most of the people on the IETF mailing list are not lawyers. So while that message was not appropriate for the IETF list, it's not fair to blame this on [EMAIL PROTECTED] - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Deployment cases
On Tue, Jan 01, 2008 at 12:46:08PM -0800, Dave Crocker wrote: In other words, I believe IMAP gets used as a MAPI surrogate, but not as a general-purpose means of accessing mailboxes supplied by consumer-oriented service providers. Those providers usually make IMAP available, but my sense is that it is not used all that much. POP seems to remain vastly preferred. I don't think that's true. A lot of people want to be able to access their mail stores from multiple clients, and POP doesn't do that well at all. MS Outlook and Outlook express both support IMAP, and you get more functionality if you use IMAP. Google's Gmail didn't support IMAP at first, and quite a large number of people complained about that. My favorite trick is to use the isync program (http://isync.sourceforge.net) to synchronize an IMAP store with a local Maildir directory on my laptop. I can then read and delete my e-mail on the laptop while disconnected from the network, and then at the end of the airplane trip, when I gain access to the network, I can synchronize my local Maildir store with the IMAP server store; e-mails which I deleted on my local machine are deleted on the IMAP server, and new e-mails that have since arrived get downloaded to my laptop. This is also great in Europe where the local wireless ISP's appear to be run by Ferengi, since I can minimize the number of minutes I need to be connected to the network. And, if anything ever happens to my laptop, I have a backup copy of my e-mail on the IMAP server, which is not usually the case with POP. (POP is vastly more inefficient if you leave e-mails on the server, since the protocol really isn't designed for that.) Basically, the combination of isync and mutt as a MUA gives me all of the advantages of Lotus Notes' disconnected operation, except it's faster, uses 10 times less memory, has decent search capabilities, and has reasonable threading support. :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Deployment cases
On Tue, Jan 01, 2008 at 03:01:04PM -0800, Dave Crocker wrote: You and I and pretty much everyone reading this email are not representative of the broader Internet community. So the question is how to document the assessment that lots of people do use IMAP. So all of the people who wanted to Google gmail to use IMAP and the fact that Microsoft Outlook and Microsoft Outlook Express support IMAP and give you more functionality if IMAP is enabled isn't at least suggestive that lots of people are using IMAP? Corporations might be using MS Exchange, but most individual end-users who are using mail service provided by the ISP are probably using IMAP. But I'm not sure why we need to prove that IMAP is success to your satisfaction. Certainly the fact that many mail providers are providing IMAP, and many MUA's can use the IMAP protocol, with more functionality to their users compared to POP, is at least in my book proof of the protocol's success. If you want to think otherwise, that's fine. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Change the subject! RE: [IAOC] Re: IPv4 Outage Planned for IETF71 Plenary
On Mon, Dec 31, 2007 at 05:36:17AM +, Greg Skinner wrote: FWIW, I reread Russ Housley's comments on the outage, and understand it to be an experiment that is voluntary (but encouraged). Perhaps this needs to be stated differently (e.g. IPv6 experiment planned for IETF71 Plenary). I think the real issue here is the difference between what was originally stated (I think first by Marshall Rose in the Open Book) as the difference between the ISO, promulgating OSI, and the IETF, promulgating TCP/IP --- which was that ISO was populated primarily by professional standard organization goers, where as the IETF was populated primarily by engineers, or doers. To the extent that you have developers who are actually helping to write code and develop reference implementations for the protocol specifications that one is helping to write, it is probably much more likely that that population is willing to hack their laptop to run IPv6 --- even if they have a locked-down laptop issued by the IT department (which very few engineers I know are willing to countenance, and will generally tend to work around one way or another), they can probably use VMware to run a sandbox environment which they *can* use to experiment. Note that this has *nothing* to do with whether the engineer uses Linux or Windows or NetBSD or MacOS as their primary laptop OS. On the other hand, if you have professional standards body attendees, who are perhaps technical enough to talk about a standard, but not enough to actually implement it, and whose primary expertise is in politics and the policies and procedures of each particular standards organization (so they know how to pack a working group or national body with representatives that will vote they want) --- they will tend to view their Windows laptop as a production environment as a sealed box, not to be touched, and only useful for e-mail, powerpoint, and microsoft word, it is much less likely they will be willing (or even able) to participate in such an experiment. Over the years, I suspect the ratio of goers vs. doers has been increasing; but I hope there are enough doers still attending the IETF to justify the Engineering in the title of the organization. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Change the subject! RE: [IAOC] Re: IPv4 Outage Planned forIETF71 Plenary
On Mon, Dec 31, 2007 at 07:23:04AM -0800, Hallam-Baker, Phillip wrote: It depends on what you consider the role of an engineer to be. I am a Chartered Engineer. The job you describe sounds more like that of a technician. Just as a chef knows evey part of the job of a sous-chef and cook an engineer needs to know every part of the job of a technician. But an engineer needs to know more. Like a chef the engineer has to accept ultimate responsibility for creating a dish the customer likes. If an engineer knows every part of the job of a technician, and the technician can make IPv6 work on their laptop, then surely an Certified Engineer should have no problems making IPv6 work on his or her laptop! :-) One of the interesting things that sometimes shows up at some of the cooking competition shows (in particular the recent competition for a new Iron Chef on the Cooking Channel), is that sometimes by the time someone achieves the title of chef, they sometimes end up getting rusty or are otherwise unable to do the job of a sous-chef competently. I certainly agree with you that the true mark of a great chef or an engineer, is that they be able to do the job of a sous-chef or a technician better most sous-chefs or technicians. Unfortunately, this is often not the case. (They can claim they are simply have no interest in trying --- I'm a *chef*, I'm too good to have to demonstrate that I can chop onions quickly, but I sometimes think that is covering the fact that they no longer have the ability.) - Ted Sent from my GoodLink Wireless Handheld (www.good.com) -Original Message- From: Theodore Tso [mailto:[EMAIL PROTECTED] Sent: Monday, December 31, 2007 06:36 AM Pacific Standard Time To: Greg Skinner Cc: Hallam-Baker, Phillip; IETF Discussion Subject: Re: Change the subject! RE: [IAOC] Re: IPv4 Outage Planned forIETF71 Plenary On Mon, Dec 31, 2007 at 05:36:17AM +, Greg Skinner wrote: FWIW, I reread Russ Housley's comments on the outage, and understand it to be an experiment that is voluntary (but encouraged). Perhaps this needs to be stated differently (e.g. IPv6 experiment planned for IETF71 Plenary). I think the real issue here is the difference between what was originally stated (I think first by Marshall Rose in the Open Book) as the difference between the ISO, promulgating OSI, and the IETF, promulgating TCP/IP --- which was that ISO was populated primarily by professional standard organization goers, where as the IETF was populated primarily by engineers, or doers. To the extent that you have developers who are actually helping to write code and develop reference implementations for the protocol specifications that one is helping to write, it is probably much more likely that that population is willing to hack their laptop to run IPv6 --- even if they have a locked-down laptop issued by the IT department (which very few engineers I know are willing to countenance, and will generally tend to work around one way or another), they can probably use VMware to run a sandbox environment which they *can* use to experiment. Note that this has *nothing* to do with whether the engineer uses Linux or Windows or NetBSD or MacOS as their primary laptop OS. On the other hand, if you have professional standards body attendees, who are perhaps technical enough to talk about a standard, but not enough to actually implement it, and whose primary expertise is in politics and the policies and procedures of each particular standards organization (so they know how to pack a working group or national body with representatives that will vote they want) --- they will tend to view their Windows laptop as a production environment as a sealed box, not to be touched, and only useful for e-mail, powerpoint, and microsoft word, it is much less likely they will be willing (or even able) to participate in such an experiment. Over the years, I suspect the ratio of goers vs. doers has been increasing; but I hope there are enough doers still attending the IETF to justify the Engineering in the title of the organization. - Ted ___ 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: Defining the term SPONSOR for the IETF
On Sat, Dec 22, 2007 at 07:23:20AM -0800, TS Glassey wrote: Ted called me on that I was using a Term of Art which has not been formally defined here in the IETF so lets define the term SPONSOR (Sponsor, SPONSOR) for use in the IETF's IP Processes. Todd, you just took a private e-mail that I sent to you and reposted part of it on the list. Some would consider that a breach of e-mail etiquette. I don't particularly care in this particular case, but fact of the matter is that defining Sponsor for use in the IETF's IP Processes is out of scope for the IETF mailing list. If the IPR-wg thinks that it is even necessary to define that Term of Art, they can do so on the IPR-wg mailing list. If the IPR-wg don't think it's in scope, there may not be any IETF mailing lists where the discussion of defining the term Sponsor may be in scope. If there are no documents where work group consensus determines that such a term is needed either for discussing a particular draft document or to use in a particular draft document, that would not be a surprising result. In any case, it is not in scope of the IETF list, and I would gently ask that you take this discussion elsewhere. Thank you. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Defining the term SPONSOR for the IETF
On Sat, Dec 22, 2007 at 09:42:14AM -0800, TS Glassey wrote: So then Ted isnt the IETF WG list isnt the place where matters without a WG are discussed? Is that true? Seems to me that the IETF cannot do that without creating a new home for projects without a WG. The IPR WG does exist. So discussions about IPR-related matters should be taken there. If they, however, decide that they don't need to define a term like Sponsor, and rule it out of scope on for the IPR working group, that doesn't mean that it is fair game for the IETF list. Regards, - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Thu, Dec 20, 2007 at 11:30:54PM -0800, David Kessens wrote: No, I don't think I missed Phillip's point at all. Some engineers are apparently more creative than others in their ability to reach the mothership over an ipv6 only network despite the fact that the mothership doesn't have ipv6 vpn support (yet). This certainly hasn't stopped me from connecting back to the company that I work for and it should not stop any competent engineer. So how about getting people to work together to document workarounds on a wiki run by the IETF? The point is if we want IPv6 to be successful we have bootstrap it by eliminating excuses. VPN access is merely the latest excuse, and it won't be the last one, either. :-) The point here is to have an engineering approach to fixing problems, by whatever means necessary. Even if the initial solutions are accomplished with bailing wire and duct tape, that's OK. They can always be fixed up later. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Let's look at it from an IETF oldie's perspective... Re: IPv4Outage Planned for IETF 71 Plenary
On Wed, Dec 19, 2007 at 11:01:28AM -0800, Hallam-Baker, Phillip wrote: The oldie perspective of 'take it or leave it' is not going to work here. I have gamed the dynamics of IPv4 exhaustion quite extensively and the mere fact that there are no more IPv4 addresses left to be allocated does not provide the forcing function people imagine. Hallam, I think the IETF oldie perspective is the amazement that people are pushing back so hard about using the IETF conference network as an early deployment/proving ground for IPv6. I remember when IP addresses were handed out on pieces of paper, and when DHCP was first deployed, and not quite reliable. Then I remember it not getting reliable again as IETF host after IETF host had to learn the hard way that Microsoft's DHCP server was cr*p (at least back then) and blew up at the scale of IETF meetings (which were much smaller back then). I suspect the real problem is the mix of IETF attendees have changed, and there are fewer people who are willing to experiment with bleeding edge technology at the network layer. I suspect these are the sort of people who are arguing that IPv4 is a production service that can't be interrupted come hell or high water, and they aren't willing to pay the pain of helping to make IPv6 work. There are also some IETF'ers who have argued that IPv6 is not the only game in town, but that NAT boxes will also work; there are other IETF'ers who have argued that IPv6 is a superior solution to NAT boxes, and that NAT boxes will either not work, or are an abomination (at least from an architectural point of view.) I'll argue that the real problem is that we haven't been serious about IPv6. If we had, people who have been pushing ICANN to solve the DNS root problem a long time ago. If we had, we would have been trying deploy an IPv6-only conference network, to make sure that technical requirements make an IPv6-only network be able to play well with the wider network (an absolute necesity from a transition point of view) either had permanent fixes, or at least had documented workarounds that work at least as well as IPv4 NAT boxes. I'm not sure whether or not the lack of workarounds are because some of the people using the IPv6 networks were too much of a network purist to use whatever workarounds would be necessary to make IPv6 work in the real world --- whether they be NAT-PT/NAT64 boxes, or DNS root hijacking, or whatever else is necessary. However, I would gently suggest that if people want IPv6 to be successful, we need to start using it, and we need to start creating the engineering solutions that allow IPv6 to be useful in the real-world. The fact that ICANN was allowed to dither until early 2008 before getting root zone records is a sign that IPv6 was not ready for the real-world for the last ten years. The question is what other real-world deployment problems are hiding that haven't been addressed yet. There are some who seem to be arguing that the IETF is not the place to work out these problems. Well, last I checked, the word *ENGINEERING* is in the name of our organization. And other groups and venues have had the last ten years to try to work out these solutions, and clear they need more help and more effort --- and I would hope the IETF collectively feels some responsibility to help out this protocol that we launched NINE YEARS AGO. Let me give a challenge. It's been nine years. In the next year, let's try to do whatever ENGINEERING work is necessary so that the IETF conference network can offer IPv6-only services to all of its laptop clients, and that this be sufficient for people to get real work done. If after a ten years --- a decade --- we can't somehow make IPv6 to be a useful production network on something on the scale of the IETF wireless network, I would argue that IPv6 really is useless and hopeless and doomed, with no way to transition to real world Internet production usage. Or maybe it would be saying something about the state of the IETF organization. I don't know - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Let's look at it from an IETF oldie's perspective... Re: IPv4Outage Planned for IETF 71 Plenary
On Thu, Dec 20, 2007 at 09:20:54AM -0800, Fred Baker wrote: Now, do you recall Randy Bush sitting in the IESG plenary and calling out passwords? Advising people to get some variation on a VPN running? For me, the big issue is that I do my work within a corporate context, and therefore need to access corporate accounts to do what I do. Cisco IT has a plan to deploy IPv6, but has not yet done so internally for a reason that will, I think, ring true for many - IPv6 doesn't solve a business problem that Cisco IT has (it has plenty of addresses for the present and has few if any IPv6-only business partners that would force the issue), and hence it hasn't seen fit to bring up IPv6 throughout Cisco. Agreed, getting VPN's to work is going to be non-trivial. On the other hand, many VPN's are designed to work even in the presence of IPv4 NAT's, since they are so ubiquitous these days; road warriors who are using a variety of hotel and airport network services run into them all the time. So the question is whether some clever engineering might allow some or all of the VPN's to work correctly even without any cooperation or assistance of the corporate VPN server? Or perhaps this might be an opportunity to encourage VPN providers to upgrade their software to work in such an environment. And if the first IETF meeting where we try this, there is a NAT box which provides IPv4 services over an IPv6 encapsulation, that might not be a bad thing. The mere fact that the IETF meeting could be only connected to the Internet via v6 and could get work done isn't a bad start. Of course, over time, the challenge to VPN makers could be made harder by adding another NAT box at the other end of the ipv4/6 decapsulation, and in future IETF's, adding successive layers of NAT boxes to the IPv4 connectivity path for those people who are sure that's the long term solution to Internet Scaling. :-) I agree that the economic considerations make it hard for the right thing to happen. This is one of the classical externalities problem, where it's hard get companies to pay attention the polar ice cap is completely gone and all the polar bears are dead. Obviously the IETF can't control the global economic picture, but we can control the IETF conference network. And the IETF does have enough of a bully pulpit that it might help shift the economic consequences. (Even if it's allowing one VPN provider to provide bragging rights that if, for example and hypothetically, the Nortel VPN solution works while the Cisco VPN solution doesn't. By giving VPN providers a chance to showcase whether their products can or can not work in an IPv6-only client environment, we can help provide the business justification for them to do the necessary development work.) - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: eating our own dogfood...Re: IPv4 Outage
Wow, that is a rather lackadisical attitude being shown by the ICANN, isn't it? I can't help thinking that if Jon Postel were still around, things would be moving a tad bit faster --- i.e., measured in minutes rather than at least months. Hmm, perhaps years; on an IANA page I see a paper authored Ronald van der Pol and some other RIPE folks indicating that they had shown it was safe to add records to the root zone, published October 2003. One would hope that they will act by the December 18th ICANN board meeting, and that any other bureaucratic hurdles would be addressed sooner rather than later. But if not, as ugly as it would have to be for the IETF to have to substitute root zone records just for the purpose of adding records for IPv6 DNS root zone servers for the March 2008 meeting, and as unfortunate as a precedent as that might set, it will have meant that ICANN will have dithered for NINE MONTHS over what seems to be a simple issue of adding IPv6 records, which means something is seriously wrong over at ICANN, and we should just fix the problem the way engineers know how to fix the problem, and let the political problem fix itself... whenever. After all, if waiting at least 9 months hasn't helped, is there any evidence that waiting another 9 months would help any more? At the end of the day, either we're serious about IPv6 or we're not. - Ted P.S. Funny, looking at the ICANN board, I have to say that I'm surprised. The board contains names like Harald Alvaestrand, Steve Crocker, Thomas Narten, in addition to the usual Lawyers and VC's. P.P.S. Obviously, this is me speaking as an individual, not with any IETF hat on, or on behalf of my employer ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: eating our own dogfood...Re: IPv4 Outage
On Wed, Dec 19, 2007 at 07:27:55AM -0500, Theodore Tso wrote: But if not, as ugly as it would have to be for the IETF to have to substitute root zone records just for the purpose of adding records for IPv6 DNS root zone servers for the March 2008 meeting Let me make it clear that I would only be suggesting this on the IETF conference network, and not making any more public than that. i.e., doing what is necessary to make a fully functional IPv6 network. This is really no different than what many companies do to the DNS for their intranet --- which maybe is a horrible idea from a BIND perspective, but is in fact quite common (where www.example.com or w3.example.com might look very different inside or outside the intranet). And if it causes some embarassing articles about ICANN to show up in the trade press, I guess at this point I wouldn't mind, terribly. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv4 Outage Planned for IETF 71 Plenary
On Tue, Dec 18, 2007 at 01:32:00PM -0500, John C Klensin wrote: (1) The only thing this exercise, as described, is going to prove is that we are skilled at shooting ourselves in the foot. We already know that, at least in the US, IPv6 is insufficiently deployed to provide a good base for communication and smooth interoperability fabric. We know that there are no IPv6 records in the root servers and that many of the root servers aren't widely connected to IPv6 networks. We know that most IPv6 use today involves tunnels between hosts or between network islands. Now we also know that skilled engineers and network operators are capable of configuring their way around those problems. But those who know how to do it know how to do it (and probably are doing it already). Inviting the rest of the community to try to sort things out in real-time in the plenary is silly at best. It will make the plenary useless and deprive us of the considerable advantages of being able to work together to resolve issues. Let me suggest another approach. Don't do this at the next IETF meeting, but make an announcement that at some near-term IETF meeting, the only internet services provided at the IETF meeting will be IPv6. Note just for an hour. Not just for the plenery. Not just for the social; but FOR THE WHOLE WEEK. In other words, let people who are using the IETF wireless network experience what it might be like in some future world where the ISP's are only providing IPv6 connectivity and IPv6 addresses to new customers. Yes, right now IPv6 deployment isn't good enough that we can't do this without using all sorts of workarounds. OK, let's document those workarounds and make them available to the attendees. If it means that the IETF network provider has to hijack the root, then let them hijack the root on the IETF network, and document that fact. If there needs to be NAT-PT bridges to allow IETF'res to get back to their home networks connected to ISP's that don't yet offer IPv6 connectivty, then let there be NAT-PT bridges --- and document them. If various Windows, Macintosh, and Linux laptops need special configuration so to work around other problems, then document what the workarounds should be, and give people early warning and access to them. The first time this gets done, it will be painful. Maybe the first and second time there should be a wired terminal room for people who weren't able to configure their laptops in advance. (Or maybe the IPv4 network can be made available over the wireless on a separate SSID with a fee attached, with the excess monies going towards making funding technical work to make the IPv6 workarounds better documented and easier to deploy for future IETF meetings, and with the IPv4 fee gradually getting raised at each subsequent meeting.) Hopefully, with each subsequent IETF meeting, it will get easier, with the number of ugly kludges and workarounds needed gradually decreasing. And maybe it shouldn't be the IETF who does this first, but some other organization which is more focused on the network providers, such as RIPE. But the point is, if a conferenceful of network engineers can't provide IPv6 to a collection of its attendees, even if ugly hacks and workarouds are needed, what hope is there for everyone else? And if we put this off because we're not ready yet, and hence fear the negative PR of failure, when will IPv6 be ready? And the press already knows that IPv6 isn't ready --- everyone knows that; so it's not a story. Now, if the entire IETF community could actually *use* IPv6 in an IPv6-only world, now *that* would be a story. And if it could use it without a huge number of hacks, that would be a stop-the-presses situation! Without a forcing function, alas, we may never be ready better that we provide a forcing function with relatively soft consequences, rather than a hard forcing function when the IPv4 address space is finally exhausted. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: eating our own dogfood...Re: IPv4 Outage
On Tue, Dec 18, 2007 at 02:05:05PM -0800, Bill Manning wrote: my appologies to Ted, you happend to be the nearest lighting rod. Heh. I hadn't realized how sensitive people are to the whole concept of hijacking the root. To me, I was thinking merely of taking the official root zone data and making it available on an IPv6 visible host, on site at the IETF meeting if that's what's necessary to make things work. I don't think of that as being particularly controversial, just an engineering expediency. What I had in mind is very different from taking the official root zone data and then adding or subtracting root entries, quite a different idea of hijacking the root. Perhaps that's what you had in mind? In any case, I did some more looking into it, and it seems that 5 of the 13 official root name servers have IPv6 addresses, and while that doesn't necessarily mean global connectivity (some of them may only have very limited service to a small IPv6 island), it shouldn't be *that* hard for the IETF network ops to arrange a one or more tunnel(s) to root servers with IPv6 addresses. But in any case, the point is let's come up with the appropriate engineering solutions so that an IPv6-only network at an IETF meeting is in fact a viable and productive resource to the attendees. And if people continue to insist that it's not possible, what does that say about IPv6? As far as my having any authority as an official spokesmodel by virtue of my Sargeant-at-Arms role, I just got a great big chuckle out of that. That title and two dollars will get me a small coffee at Starbucks! - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: eating our own dogfood...Re: IPv4 Outage
On Wed, Dec 19, 2007 at 02:20:32PM +1100, Mark Andrews wrote: On Wed, Dec 19, 2007 at 11:36:34AM +1100, Mark Andrews wrote: The problem is getting the records for them published. A local copy of root-servers.net with the records added will suffice. www.root-servers.org will supply you with the necessary information to construct such a zone. Ok, so I'm sure this is a REALLY dumb question, but what has prevented anyone from taking the informatoin from www.root-servers.org and creating a named.boot file with both the A and records for the root nameservers, and started telling people to install it? named.boot is not used after the priming succeeds. Ah, right. So that's why we would need to hijack the root zone information --- so we can add the records to the root zones. OK, next stupid question? Why aren't the records being published in the official root zone today? Is there some good reason, like say the size of the records returned for the root zone being too big? And is something being done to address whatever reasons might exist, whether they are at the technical or political layer? - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IETF Hosting Opportunity - March 2009
On Thu, Nov 29, 2007 at 10:15:05AM +0100, Stephane Bortzmeyer wrote: It's not geographic balance of places on the world map that people are talking about here. It's geographic balance of places where the people who write IETF documents live. Then, things can go on forever. We do not hold meetings in places where there are not a lot of IETF members. As a result, people from these countries do not come and do not participate. Then, the prophecy becomes true. And so on. If we want to be serious about breaking the vicious circle, we should do meetings in places where there is *currently* few members (I do not suggest Namibia or Papua-New Guinea but, may be, Egypt, Argentina, India, places like that?) I would have to disagree. How useful is it for someone who isn't participating with the IETF to show up at an IETF meeting for the first time with zero context? The best way to participate is *on* *the* *mailing* *lists*. If we have the meeting in the middle of Africa, do you honestly expect anyone who shows up out of curiosity is likely to start authoring IETF documents and participating with the IETF after that one meeting is over? I personally have trouble beliving this - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Putting requirements on volunteer tool developers (Was: Re: Daily Dose version 2 launched)
On Wed, Nov 07, 2007 at 01:06:31PM -, [EMAIL PROTECTED] wrote: Frankly I have no idea what this whole tempest is about and I don't know why you want to drag this onto the open list. Because you were the one who kvetched on the open list, perhaps? :-) My recommendation to the tools people when they receive whining complaints or even suggestions is the same as any other open source developer. Either, that's a good idea, I'll have it by next week, or good idea, it's on my TODO list, or patches will be gratefully accepted for review. :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A priori IPR choices
On Thu, Oct 25, 2007 at 06:00:42PM +0200, Norbert Bollow wrote: I would argue that a GPL implemention is not important to interoperability testing as long as there is a BSD-licensed implementation. In fact, to the extent that all or most of the commercial products are based off of the same BSD-licensed code base, this can actually *improve* interoperability. (I may have been awarded the 2006 FSF Award for the Advancement of Free Software, but if my goal were to make sure that specification was going to get widely adopted, I'd use a BSD license, not a GPl license, for the reference implementation.) I don't disagree with anything that you wrote, but the point here is that if there's a patent with GPL-incompatible licensing, you don't have permission to link that BSD-licensed code into a GPL-licensed program and distribute the result. And I would argue that the above issue is not a matter of concern to the IETF. Having a reference implementation to encourage adoption of the spec, that is of IETF's concern. The issue of GPL requirements is, I would argue, Not Our Problem. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A priori IPR choices
On Thu, Oct 25, 2007 at 07:09:54PM +0200, Norbert Bollow wrote: And I would argue that the above issue is not a matter of concern to the IETF. Having a reference implementation to encourage adoption of the spec, that is of IETF's concern. The issue of GPL requirements is, I would argue, Not Our Problem. Is it really your position that that is in no case a concern that IETF should consider??? For an extreme example, consider hypothetically the case that an essential part of the IPv6 protocol stack had such a patent issue. I was thinking mainly about protocols used by application programs. I agree that something essential needed for IPv6, that might be something that an individual wg might want to consider. But in terms of a blanket policy that would apply to *ALL* IETF protocols? That would something that is really NOT an IETF-wide concern. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A priori IPR choices [Re: Third LastCall:draft-housley-tls-authz-extns]
On Tue, Oct 23, 2007 at 01:04:32PM -0700, Ted Hardie wrote: I believe it is fairer to recognize that in your example proposal B is known to have been patented where A is not. There is always the chance that someone will turn out to have secured rights which they later claim read on A. In that case it may actually be better to choose B, knowing that the license offered works for the development and deployment community than to choose A. In other words, a defensive patent declaration by someone whose license works for the appropriate community may actually add security. It doesn't completely remove the risk that someone will turn up with other rights, but it really can help. This doesn't follow. Just because a company has patents that read on B doesn't guarantee some other company *also* has patents that read on B. So you can't say with certainty choosing path B is better than path A just because a company has already declared they have patents that read on B. The US Patent Office may have simply issued two patents on the identical technology (I believe the cannonical example is the case where three patents were issued covering the same compression algorithm). Or there may have been other aspects of B that happened to be patented by another company, and if it is currently owned by a Patent Troll who has no interest in participating in the IETF process, there is no way for the working group to know about the Patent Troll's patents. Aren't patents fun? :-) - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A priori IPR choices
On Tue, Oct 23, 2007 at 01:05:39PM +0200, Simon Josefsson wrote: Frank Ellermann [EMAIL PROTECTED] writes: http://tools.ietf.org/html/draft-josefsson-free-standards-howto. I noticed that the 00 draft would expire in two days, and submitted a 01 with only minor changes. I like this document a lot; kudo's to Simon for writing it! My personal opinion is that suggestions for how to write a free standard published as an informational RFC is much more useful than trying to get consensus around some edict that the IETF _only_ publish free standards. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: A priori IPR choices
On Tue, Oct 23, 2007 at 03:10:29PM +0200, Simon Josefsson wrote: Frank Ellermann [EMAIL PROTECTED] writes: Do you refer to the IBM patent on BOCU? As far as I have understood, IBM promised to grant a free patent license to people who requested it, but people never received a license despite requesting one. If this is accurate, I think it is a good example of a technology that should not be standardized and should not be promoted by the community. Can someone give an example of someone who has requested a license but not received one, please? (For reference, there is a copy of a letter which was apparently sent from IBM to the Unicode consortium here: http://unicode.org/notes/tn6/) Since the letter was sent in January 2006, IBM has moved to a new way of dealing with patents and standards, with its Interoperability Specification Pledge, which is essentially an irrovocable covenant not to assert any Necessary Claims to anyone making, using, importing, selling, or offerring for sale any Covered Implementations, with a broad defensive clause. This was announced in July of this past year, and more details can be found here: http://www-03.ibm.com/linux/opensource/ispinfo.shtml BOCU is not on the list of Covered Specifications, but my guess is that such an omission is very likely due to an oversight rather than any kind of maliciousness. The good news is this new framework doesn't require any kind of formal request to obtain a patent license, and so hopefully a request to move the offer of a RF license covering BOCU to the Interopreability Specification Pledge framework would hopefully take care of your issue. - Ted P.S. All opinions stated above are my own, and do not necessarily reflect IBM's positions, strategies, or opinions. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, Apr 11, 2007 at 10:27:31AM +0200, Brian E Carpenter wrote: 1) You seem to assume that GPL implementers would violate the patent license by redistributing their code without sending a postcard. In order words, your question assumes and implies bad-faith amongst GPL implementers. Not specifically. My question is a practical one. People who receive open source code, tweak it, and install it may often be completely unaware that they should be asking for a license. Do we have any practical evidence that IPR owners actually care? Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? What typically happens in practice, among good-faith practitioners, is that there won't be any GPL (or Apache, or Mozilla, or ...) implementation of the patented technology at all, because the necessary rights cannot be acquired. Doesn't that sound like a bug in the OSS licenses to you, assuming the desired result is to make the Internet work better? It's not bug in the OSS licenses at all. Rather, it's a choice (based on ethics/legal paranoia/whatever) of implementors not to risk having to spend millions and millions of dollars defending a patent lawsuit. In some cases, paranoid corporate lawyers might be involved as well, telling implementors that if they can't fulfill the terms of the patent license, they may not write or release code which could potentially result in a lawsuit claiming the person implementing said patented technology was inducing end users to infringe (since it's pretty much axiomatic that 99.99% of people downloading code won't know that they need to send a postcard). I suppose if the RF license allow a program to automatically send an HTTP request to automatically request a license --- but that seems like a great way to slashdot the IPR holder's web servers, if an open source software package using said RF license gets popular! Let's reverse the question --- why do IPR holders feel they need people to explicitly request a royalty-free license? It seems like it's just unnecessary administrative work on their end for no cost. Unless, of course, it's not perpetual, as was alleged with a certain XML office document patent grant, which meant that a certain company could pretend to release sofware under what appeared to be a Royalty Free License, but then required every user to go on bended knee to request a license, which could be denied at any point in the future if said company changed its mind. The state of Massachusetts chose to use the OASIS Open Document format partially because of this concern, so such patent licensing choices can make a huge difference in terms of standards adoption. So to me this seems to be more of a question similar to the controversy of labelling food as Organic. There will be companies that may want to label their patent licenses as Royalty Free, but not necessarily make them be perpetual, or require each individual end user to fill out a form and mail it via paper mail and wait for a paper response before they wouldn't be infringing the patent --- but the net result of it may be to inhibit using the patent unless actual dollars are paid to the IPR holder. No question, that is the right of the IPR holder to do so, to the extent granted by the relevant legal jurisdition(s). But the question is whether they should be allowed to call such a patent royalty free --- either by creating some set of standards which are trademarked, much like the Open Source Definition did for copyrights --- or by some organization, like the IETF, refusing to a characterize a patent license as being royalty free (or pick some other term denoting that the license could actually be practically used in Open Source Software). And like the massive debates over organic foods, there will no doubt be a lot of debate and disagreement about what those standards should be. - Ted Disclaimer: These are my own personal opinions and not necessarily the opinions of my employer; I'm not important enough to affect the opinions of my employer. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, Apr 11, 2007 at 01:54:53PM +0200, Brian E Carpenter wrote: Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? My assumption is that they care if the party that fails to send a postcard is one of their competitors. That's what the defensive clauses in these licenses are all about, afaics. So if there is a license which is not sublicensable, where if a competitor wanted to field a product that required the patent license --- I would rather doubt it if the competitor would want to ship software or hardware where each individual end user had to send a signed, notarized paper form to the IPR holder, and wait for a paper response, before they would be allowed to use that product. So that brings up an interesting question. Suppose an IPR holder approached the IETF, with a claim that they were offerring an royalty free license, but one which was not sublicensable and which contained extremely onerous terms that applied to the individual end user. (``After receiving an individually framed patent license, the end user must jump up and down 17 times on one foot while chanting, Hail Billy, the Gates is with you, I promise to never use Open Document.'' :-) Now suppose the IPR disclosure filed with the IETF didn't say anything at all about any reasonable and nondiscriminatory licenses alternative to said royalty free license. At this point, we could end up with a situation where a company tries to implement an IETF standard, realizes that the reliance on the royalty free license is untenable, goes back to the IPR holder, only discover that the only other alternatives are under terms which are anything but RAND. So at the minimum, if we're not going to establish requirements on royalty-free licenses being at least (a) perpetual, and (b) automatically sub-licensable, (maybe those could be defined as part of reasonable as it applies to RF licenses?) it would probably be a good idea to require a statement by the IPR holders to state their position on a RAND licensing as well. Otherwise, we could end up in a situation where we discover after the fact that the only way to implement the standard is via a completely unreasonable set of royalty-free terms that make it completely useless for either an OSS or commercial/propietary product, and with no statement about RAND licensing terms. Basically, there seems to be a loophole in our current wording which could allow a bad actor who was determined to use patents as a strategic weapon a way to lay trap which could seriously compromise the deployment of an IETF standard. - Ted P.S. For the record, my personal list of reasonable RF license terms include: 1) Perpetual (MUST) 2) Sub-licensable (MUST) 3) Restriction to essential claims necessary to implement a standard (MAY) 4) Defensive clauses which revoke a patent license in the event of patent litigation (MAY) (Some OSS advocates will disagree with me on #3, and there I will agree with Brian that if an OSS requires a universal patent license, it's probably a bug in the OSS license --- and the ones who try to use the OSD language about fields of endeavor are trying to apply standards designed for copyright licenses, and they may not be appropriate for patent licenses. But there will be plenty of room to debate this particular issue --- but probably better to do it in the IPR working group. :-) --- Disclaimer: These are my own personal opinions and not necessarily the opinions of my employer; I'm not important enough to affect the pinions of my employer. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, Apr 11, 2007 at 01:54:53PM +0200, Brian E Carpenter wrote: Ted, Well, if IPR owners don't actually care, why are they asking people to send a postcard? It would seem to be an unnecessary administrative burden for the IPR owners, yes? My assumption is that they care if the party that fails to send a postcard is one of their competitors. That's what the defensive clauses in these licenses are all about, afaics. I was thinking about your response, and I wonder if we might be talking past each other. The concern that I think a number of raising about send a postcard specifically about patent licenses which are not sub-licensable, so that each individual end-user has to request their own individual patent license. Were you perhaps thinking of the scenario where only the a developer had to do is to send a postcard to request a patent license? If so, I agree that's much less of an issue, although it still could potentially be considered too onerous by some. We could construct some really extreme ways such a Royalty Free license could be worded that illustrates how our lack of definition of Royalty Free in the IPR disclosure template could come back to haunt us. Suppose a company declared that they would make a Royalty Free license available. If they subsequently published the the following, at which point would it be construed that they had violated the IPR declaration (of which I hope some lawyer has commented about whether or not it is legally binding)? This patent license is not sub-licensable. Each developer and individual end user must travel in person to the MegaCorp offices located in Nome, Alaska, and apply for a royalty-free patent license, which shall not be refused unless you or your company has ever used or developed software which utilizes the Open Document format. If the answer is that a company could declare in an IPR declaration that they are offerring an Royalty Free license, and not make any promises for offerring RAND terms, and then could offer their patent under the above license without sufferring any legal consequences, I'd argue we have a significant hole in our processes. - Ted Disclaimer: These are my own personal opinions and not necessarily the opinions of my employer; I'm not important enough to affect the opinions of my employer. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Withdrawal of Approval and Second Last Call: draft-housley-tls-authz-extns
On Wed, Apr 11, 2007 at 01:24:02PM -0400, John C Klensin wrote: Ted, jumping ahead a little bit, how much of your concern would be eliminated if that entry in the template said Royalty Free and RAND (or RAND and Royalty Free), rather than just RF? I agree that RF and totally unreasonable is a possible case, but am trying to understand whether we have a disconnect about the language we have used or about some general and important principle? I believe that this is the minimum we should have just simply to protect the needs of commercial/propietary consumers of our standards, so yes, that addresses much of my concern. I believe it would be better if Royalty Free were more strictly defined to include irrevocability *AND* either (a) the ability to sublicense or (b) the ability for end-users to automatically get a grant of permission without having to perform any explicit action, as was done in Microsoft's Open Specification Promise. Unlike some OSS advocates, I don't feel a particular need to to require a patent license which is valid for any field of endeavor; just the essential claims necessary to implement an IETF standard is IMHO sufficient (realistically I doubt many IPR holders would be willing grant more than that). And I suspect there is general consensus that terms which revoke permission in case of patent litgation (even the GPLv3 has such terms) is not controversial at all. But regardless of what definition we end up, I think we should more explicitly define what we mean by Royalty Free, just to prevent companies from engaging in PR/Marketing games. If it ends up being a definition which means that it might not necessarily be useful to OSS implementors (i.e., the end-user must in apply in person at the offices of MegaCorp in Nome, Alaska example), at least it's well defined and people are put on notice that they can't trust the IETF when we say something is Royalty Free that the specification could be really implemented by Open Source Software developers without doing more digging into the details of the license --- which might not be in the IPR disclosure. It's not ideal, but at least people would know where they stand. - Ted Disclaimer: Any opinions expressed in this message are my own and does not necessarily reflect the opinions of my employer. I'm not important enough to affect the opinions of my employer. :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: nomcom and confidentiality
On Tue, Nov 07, 2006 at 05:37:37AM -0800, Harald Alvestrand wrote: I think some of Laksminath's concern is valid. But I think the solution to the problem is simple: Make it publicly known who is on the technical staff that supports the Nomcom, and make it clear that these people: 1) May learn Nomcom information as a side effect of their technical work to support Nomcom 2) Have promised not to reveal that information to others, and have promised not to take any other action based on that information (apart from fixing technical problems) This is analogous to the role of an email postmaster: He *can* read any mail on the system, if he really wants to, but we trust him to not *do* it - or, if he has to during debugging, we trust him to forget what he's read. If people are so paranoid^H^H^H^H^H^H^H^Htouchy about this subject, that's a good thing of course. But unless people are using PGP or S/MIME to encrypt all traffic to and from the nomcom list these days, note that this list won't be complete. You would also need to include all of the e-mail postmaster staff servicing the e-mail addresses of everyone on the nomcom And if you don't force people to encrypt traffic on the inbound side, and just do the PGP encryption at the reflector (a common setup), someone who is sniffing packets in the corporate intranet of any of the nomcom members could also acquire quite a bit of significant information, from the quoted replies as well as the from the posted text of said nomcom members --- and let's not forget the fileserver/backup admins if people are decrypting the messages and storing the messages in their decrypted form in their NFS home directories. For the joke impaired --- I'm taking this to extremes just to show how silly we can get --- or, if you are truly paranoid and wanting to treat this information as carefully as the US government might want to treet Top Secret classified information, to point out how hard this would be and how this would almost certainly impact on the productivity of the nomcom. Some amount of common sense is required here, obviously. I trust that Henrik thought this was so obvious it didn't need mentioning. I would have thought this was kind of obvious, but maybe that's because I had postmaster duties at MIT for almost a decade - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: 'Progressive Posting Rights Supsensions' to ...
For the record, I'm personally against rescinding 3683 at this time. I will note that the one actually setting up the PR-ACTION was quite disruptive (and I haven't been on the IESG so I haven't felt their pain, I know), once the PR-ACTION *has* been set up, the amount of effort to deal with someone who has been engaging in abusive posting on the IETF list is requires less time than going through the process of multiple suspensions, each of which has the pontential of triggering a complaint to the IAB. Is the tradeoff worth it? Well, with the knowledge that I am probably baised (and I am disclosing that bias, as it's less work for *me* :-), I'd say yes. - Ted P.S. Given the number of e-mails that I get from folks saying, Why haven't you taken action **sooner**?, hopefully people will realize that the current IETF seargeant-at-arms have been very conscious about wanting to err on the side of allowing more noise, rather than going overboard with squelching dissent on the IETF list. The reality, though, is that most of the work is caused by a very small number of individuals, so it may very well be worth the effort to go through the pain of getting a 3683 PR-ACTION pased once, as opposed to amortizing it over many mailing lists and multiple incidents. But, that's just my opinion. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: I understand that there is an ISO MOU with the IETF - I want to see it...
On Fri, Oct 13, 2006 at 01:50:46AM -0700, Harald Alvestrand wrote: (Note - there is an ITU-T Recommendation that talks about almost exactly what is being described. It is documented in RFC 3356, which is shared text with ITU-T A-Series Supplement 3. This is, however, not an MOU; it's an ITU description of its internal procedures. It's possible that ISO and ITU got mixed up somewhere along the line.) Err, no, I wouldn't call RFC 3356 a Memo of Understanding. (Remember, you're answering a question that was posed by someone who tends to be extremely legalistic and who likes to issue legal advice without being a lawyer. So, you have to be very careful about your terms.) In general, a Memorandum of Understanding is generally understood to be documenting points that were made after some negotiation which generally has the force of a contract. It is sometimes thought of a as a simple contract, and the term probably started as a way of evading legal review by a company's legal department by not calling itself a contract, but just a memo of understanding between to company's representatives. But over time it has acquired the connotation of something fairly formal and generally legally binding. For example of this, take a look at RFC 2860, Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority, which was written in the style of a contract and signed by Fred Baker (IETF chair), Brian Carpenter (IAB chair), and Mike Roberts (President, ICANN) as such. In contrast, RFC 3356 is not legally binding, and in fact describes itself as a document providing guidance to aid in the understanding --- where understanding is generally of mapping the meaning of words and organizational structures between the two organizations' cultures (you say lorry, we say truck), and suggestions about how to work together (mailing Word documents to an IETF list is discouraged). However, it is NOT a legal document that is formally agreed-to by both sides, but rather an explication of each party's existing policies and procedures so the two organizations might be able to work together effectively. If you look at the tenor of RFC 3356 and RFC 2860, you will hopefully see there is a massive difference between the intent and style of thw two documents, and in fact RFC 3356 says nowhere that it is a MOU. - Ted ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
