Re: paralysis
At 3:03 PM -0800 3/7/04, Michael Thomas wrote: From what I can tell, anything that falls short of perfection then gets summarily executed. The majority of the anti-spam proposals being actively discussed are variants on the prove the sender is who he says he is. None of these are perfect, yet: - they are being actively discussed in the ASRG - they are being actively discussed on the [EMAIL PROTECTED] mailing list - there was a BOF about them last week in Seoul - some people are creating experimental implementations and looking at the results This seems different than summarily executed. --Paul Hoffman, Director --Internet Mail Consortium
Re: visa requirements (US citizens)
At 10:46 AM -0800 1/28/04, Kevin C. Almeroth wrote: The Korean embassy page that is linked to from the IETF meetings page (http://www.koreaembassy.org/visiting/eng_visas.cfm) makes it pretty darn clear that US folks should get a visa. They do have a link from that page saying how wonderful US-Korea relations are, of course. What part are you reading that says this? # You may enter Korea without a visa for a stay up to 30 days or less for tourism, visiting, or transit to another country when carrying a valid US passport. Seems to me to pretty clear that a visa is not needed. I am not a lawyer, but I don't think attending a professional meeting is either tourism, visiting, or transit to another country. YMMV. --Paul Hoffman, Director --Internet Mail Consortium
Re: visa requirements (US citizens)
At 2:31 PM -0500 1/27/04, Steve Bellovin wrote: I was advised by our corporate travel consultants that I should get a visa. Given the current international climate -- there was an article in last Thursday's Wall Street Journal about how other countries are retaliating for the current U.S. fingerprinting and visa application requirements -- this may be a prudent course of action. The Korean embassy page that is linked to from the IETF meetings page (http://www.koreaembassy.org/visiting/eng_visas.cfm) makes it pretty darn clear that US folks should get a visa. They do have a link from that page saying how wonderful US-Korea relations are, of course. Showing up in the airport without a visa and saying but someone at one of your consulates told me I didn't need one may go over as well in other countries as it does in the US... --Paul Hoffman, Director --Internet Mail Consortium
New mail-ng mailing list open for sign-ups
Greetings again. There seems to be more discussion these days about replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of reasons. The discussion seems to pop up on a few different lists and in a few different hallways, and it might be good to have a single list where folks can congregate. Thus, I have set up a mail-ng mailing list. The first task probably is to determine what the next generation of mail should do, and how that is different than what SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say that we can ignore actual protocol proposals for many months (if not years) until we figure out what is needed. Once we do that, there are plenty of protocol people who can attack the decided-on requirements. There is no expectation that there will be significant agreement on the list. It is likely that over time the discussion will split into camps of like-minded design goals. The list might then spawn different lists for the folks of the different camps (mail-ng-shoe, mail-ng-sandal, ...). The list is explicitly not yet meant to be an IETF working group yet (if at all), and is probably more akin to the IRTF. But at the beginning, it will most likely be talking, not research. See http://www.imc.org/mail-ng/ for information on how to subscribe. The list is taking subscriptions now, and will probably go live for discussions within a week. Having some discussion on a mailing list now should make the dinners and bar gatherings at Seoul more interesting. --Paul Hoffman, Director --Internet Mail Consortium
New mail-ng mailing list open for sign-ups
Greetings again. There seems to be more discussion these days about replacing SMTP and/or RFC 2822 and/or POP/IMAP for a variety of reasons. The discussion seems to pop up on a few different lists and in a few different hallways, and it might be good to have a single list where folks can congregate. Thus, I have set up a mail-ng mailing list. The first task probably is to determine what the next generation of mail should do, and how that is different than what SMTP/2822/POP-or-IMAP or instant messaging does. It is safe to say that we can ignore actual protocol proposals for many months (if not years) until we figure out what is needed. Once we do that, there are plenty of protocol people who can attack the decided-on requirements. There is no expectation that there will be significant agreement on the list. It is likely that over time the discussion will split into camps of like-minded design goals. The list might then spawn different lists for the folks of the different camps (mail-ng-shoe, mail-ng-sandal, ...). The list is explicitly not yet meant to be an IETF working group yet (if at all), and is probably more akin to the IRTF. But at the beginning, it will most likely be talking, not research. See http://www.imc.org/mail-ng/ for information on how to subscribe. The list is taking subscriptions now, and will probably go live for discussions within a week. Having some discussion on a mailing list now should make the dinners and bar gatherings at Seoul more interesting. --Paul Hoffman, Director --Internet Mail Consortium
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 12:48 PM -0500 1/13/04, [EMAIL PROTECTED] wrote: On Tue, 13 Jan 2004 07:21:53 EST, [EMAIL PROTECTED] (Mike S) said: As I said, fascist. Godwin. Valdis, you have confused two protocols that produced similar results but used different underlying transports and different signalling. --Paul Hoffman, Director --Internet Mail Consortium
Re: Has anybody heard back from the Hotel in Seoul?
At 2:39 PM -0600 1/5/04, Pete Resnick wrote: I got no response (other than an initial e-mail telling me I filled out part of the form incorrectly, which I answered by e-mail). After hearing nothing, I called them and got a confirmation number. Perhaps it is a NACK rather than an ACK protocol? Not to worry everyone, but I got an ACK via FAX a few days after I faxed them my reservation. --Paul Hoffman, Director --Internet Mail Consortium
Re: Tag, You're It!
At 12:47 PM -0500 12/17/03, John Stracke wrote: Paul Hoffman / IMC wrote: At 9:55 AM -0500 12/17/03, John Stracke wrote: Modifying the Subject: line is a Bad Thing; it invalidates digital signatures. Which digital signatures are you talking about? Neither S/MIME nor OpenPGP sign the headers in messages, only the bodies. S/MIME can sign the Subject: header (see RFC-1848, section 6.3) RFC 1848 is for MOSS, not S/MIME or OpenPGP. MOSS had no significant implementation. --Paul Hoffman, Director --Internet Mail Consortium
Re: PKIs and trust
At 12:12 PM -0500 12/14/03, Keith Moore wrote: To further your point, an area completely outside of ICANN's purview, yet an area requiring governance is PKI. We are at the point where deployment of a PKI has moved beyond technical issues, becoming almost completely the policy politics of trust. Until the politicians broker the trust relationships, there is nothing technology can do. since when are politicians trustworthy enough to broker trust relationships? I'd put this a different way. Until PKIs are able to represent the rich diversity of trust relationships that exist in the real world, they are mere curiosities with marginal practical value. Oh, please. Describe a trust relationship that cannot be represented using current PKI technology (PKIX certs, S/MIME signed messages, OpenPGP certs, OpenPGP signed messages, or SPKI certs). The lack of ability to represent the trust relationship is not what is stopping the PKIs. --Paul Hoffman, Director --Internet Mail Consortium
Re: PKIs and trust
At 2:14 PM -0500 12/14/03, Keith Moore wrote: I'd put this a different way. Until PKIs are able to represent the rich diversity of trust relationships that exist in the real world, they are mere curiosities with marginal practical value. Oh, please. Describe a trust relationship that cannot be represented using current PKI technology (PKIX certs, S/MIME signed messages, OpenPGP certs, OpenPGP signed messages, or SPKI certs). I trust my boss to make statements about my job. I trust my landlord to make statements about the house I rent from him. I trust my mother and my siblings to make statements about my immediate family. I trust my mother and my siblings to make statements about the identities of other family members. I trust the State of Tennessee to make statements about the identities of state agencies. I trust state agencies to make statements about which they have authority: (e.g. automobile licensing) but not to make statements about things that are outside of their purview. I trust the United States government to make statements about the identifies of US government agencies. I trust US government agencies to make statements about which the agency has authority: (e.g. aircraft licensing, federal income tax) but not to make statements about things which are outside of their purview. I trust my employer to make assertions about the identities of its officers and/or other employees, for the purpose of establishing identity for work-related communications, but not for other purposes. Now if you can show me a tool that will translate statements like the above (or other statements that ordinary humans can understand) into data structures that existing PKI-based tools will interpret reliably and correctly, I'll be extremely impressed. All of those statements, assertions, and so on can be made in simple signed messages. When you get a message with statements about your job, you verify that the message has been signed using your boss' public key. What's the problem here? --Paul Hoffman, Director --Internet Mail Consortium
Re: PKIs and trust
At 2:48 PM -0500 12/14/03, Keith Moore wrote: All of those statements, assertions, and so on can be made in simple signed messages. When you get a message with statements about your job, you verify that the message has been signed using your boss' public key. What's the problem here? Some of the problems occur when I start trusting software to tell me whether to believe in the identity, authority, or role claimed by someone I don't know personally. It gets worse if I start trusting software to make decisions based on the things that people I don't know personally tell me. You're talking about a problem with software, not with the standards. You started this thread with: At 12:12 PM -0500 12/14/03, Keith Moore wrote: Until PKIs are able to represent the rich diversity of trust relationships that exist in the real world, they are mere curiosities with marginal practical value. PKIs are able to represent the blah blah blah; your software isn't yet translating that into something that you want to use. --Paul Hoffman, Director --Internet Mail Consortium
Re: PKIs and trust
At 2:52 PM -0500 12/14/03, [EMAIL PROTECTED] wrote: On Sun, 14 Dec 2003 11:33:23 PST, Paul Hoffman / IMC said: At 2:14 PM -0500 12/14/03, Keith Moore wrote: I trust my boss to make statements about my job. All of those statements, assertions, and so on can be made in simple signed messages. When you get a message with statements about your job, you verify that the message has been signed using your boss' public key. What's the problem here? Please explain how you enforce that the signed part of the message *only* contains statements about his job, and does not make any claims that he doesn't trust his boss to make, but does trust his landlord to make? As the person trusting something, I don't have to enforce anything: I look at it and make a trust judgement. If you are assuming that this trust has to be made automatic, then you first need to scope the kind of statements that can be made. You then describe that scope in the boss' certificate. Note that this isn't a hypothetical. This message is signed, and it quotes you quoting Keith. Or at least it claims to. Now what does the signature tell you about the words that Keith is attributed with? Absolutely nothing - you get to rely on your judgment of how careful I am with attributing quotes. Exactly right. I don't trust you to quote Keith or me. So? At our site, we have multiple people who are authorized to sign purchase orders. Explain a simple signed message format that explains to the vendor that the digitally signed PO from Mary Smith for desktop computers is OK, because Mary is authorized to buy those for us, and the PO from Richard James for concrete for construction project #11934 is OK - but Richard isn't allowed to buy desktop computers or concrete for other projects. All of that is describable, and many vendors have such products. There are no standards (or none that are significantly followed) for such assertions. So? Many different PKIs can handle such assertions, once you codify them. --Paul Hoffman, Director --Internet Mail Consortium
Re: PKIs and trust
At 4:29 PM -0500 12/14/03, [EMAIL PROTECTED] wrote: On Sun, 14 Dec 2003 12:09:37 PST, Paul Hoffman / IMC said: All of that is describable, and many vendors have such products. There are no standards (or none that are significantly followed) for such assertions. So? Many different PKIs can handle such assertions, once you codify them. I'm having a very hard time as reading this as anything except Sure, the PKI's out there could do it, if we only understood it well enough to come up with a consistent way that would work for everybody. And since the PKI could deal with it if we knew what we wanted it to deal with, it's not a problem for actual production use of a PKI now. Try harder then. Maybe try The PKI works fine for this, as does the signed messages, and we understand what we want, but we can't figure out how to trust the other humans in the process. You can't find a consistent way that would would for everybody if they can't define why and how they trust each other. There are literally billions of dollars that can be saved if someone can figure out how to get the human trust part to work. Given that the technical end of the PKI world has not changed much in the past five years, it's pretty clear that if someone is leaving billions of dollars on the table, the problem is pretty difficult and not prone to a technical fix. This has nearly nothing to do with the technical part of the PKI, and everything to do with the humans. --Paul Hoffman, Director --Internet Mail Consortium
RE: ITU takes over?
At 8:39 AM -0800 12/12/03, Tony Hain wrote:
vinton g. cerf wrote:
...
Unfortunately, the discussion has tended to center on ICANN as the only
really visible example of an organization attempting to develop policy
(which is being treated as synonymous with governance
To further your point, an area completely outside of ICANN's purview, yet an
area requiring governance is PKI. We are at the point where deployment of a
PKI has moved beyond technical issues, becoming almost completely the policy
politics of trust. Until the politicians broker the trust relationships,
there is nothing technology can do.
s/politicians/politicians and business community/
Absolutely agree with this sentiment. Anyone who starts an anti-spam
proposal with All we need to do is digitally sign the {messages|SMTP
transmissions}... is completely unclear on how little governance
there is in this area.
--Paul Hoffman, Director
--Internet Mail Consortium
Re: just a brief note about anycast
At 3:30 PM +1200 12/9/03, Franck Martin wrote: And one important fact, is that IETF issues standards which do not contain patents... but ITU does! It depends on what you mean by do not contain patents. If you mean that are not covered by any patents, then tropical living has really affected your view of IETF reality. Reading http://www.ietf.org/ipr.html will possibly drag you back to where the rest of the folks on this mailing list reside. --Paul Hoffman, Director --Internet Mail Consortium
Re: How to submit a draft
At 4:21 AM -0800 11/21/03, Dinesh Kumar wrote: Could someone tell the procedure for submitting a draft to IETF. See The Tao of the IETF at http://www.ietf.org/tao.html. --Paul Hoffman, Director --Internet Mail Consortium
Re: i18n name badges
There are going to be *at least* three desirable encodings of a person's identity -- the 'natural' encoding in the preferred/native charset of the person's name, some kind of phonetic-ASCII encoding that tells non-natives how to pronounce the name, and the email/idna encoding[s] that folks would use to exchange mail. Folks: it has *not* been decided that there will be a different encoding for email. One such encoding has been proposed; other proposals have been made. This is being actively discussed, and there should be no assumption that the discussion will end with a new encoding. --Paul Hoffman, Director --Internet Mail Consortium
Re: Plans for IETF - 60
At 10:41 AM -0500 11/19/03, Brett Thorson wrote: I am hoping to get this done in time for IETF 59, but with current workload here at the IETF, I am going to aim for 60. Something else to add to the list: make software available for popular OS's that help the NOC team document the problems. For example, it would be grand if I could tell you which MAC just hijacked my network connection and turned it into a peer-to-peer connection. The software should be available for Win2K and later, as well as OS X. I suspect that the software is already available for Linux and BSD; all you need is instructions on which commands to use to get the data that is valuable to the NOC. --Paul Hoffman, Director --Internet Mail Consortium
RE: IETF58 - Network Status
Sitting in the Thursday plenary, I note none of the network-to-ad-hoc flappage that have been plaguing us the past few days. Did the attackers get bored and go home? Did the accidental ad-hocers finally get their settings right? Did someone deploy a good blocking mechanism? --Paul Hoffman, Director --Internet Mail Consortium
Location of the IMAA list (was: RE: FYI: BOF on Internationalized Email Addresses (IEA))
At 11:54 AM -0500 10/28/03, [EMAIL PROTECTED] wrote: The BOF description lists [EMAIL PROTECTED] as the discussion list, but this discussion is being cc:ed to [EMAIL PROTECTED] I'd suggest that you move this discussion to whichever of those lists is actually correct. It is [EMAIL PROTECTED], although because Patrik sent out the wrong address, I have made sure that both addresses work. An archive of the list, and links to the current versions of the drafts, can be found at http://www.imc.org/ietf-imaa/. No more messages to all lists: that's what the IMAA list is for. --Paul Hoffman, Director --Internet Mail Consortium
Re: How to bulid a new group?
At 11:07 AM +0800 10/3/03, wang liang wrote: If I find there is no a group for some important issues about Internet, and It may be necessary to build a new one,what should I do?Who will deal with this kind of suggestion?Where can I find the detailed process of asking for a new work group?thanks. See http://www.ietf.org/tao.html for probably everything you need to get started. --Paul Hoffman, Director --Internet Mail Consortium
Re: [Fwd: [Asrg] Verisign: All Your Misspelling Are Belong To Us]
At 2:14 PM +0200 9/18/03, Francis Dupont wrote: = IMHO it should reject SMTP connection from the beginning with the 521 greeting described in RFC 1846... People are unhappy about VeriSign breaking the rules. But here you are proposing that they follow an *experimental* RFC whose rules were not accepted into the later revision of SMTP in RFC 2821. How will them breaking the rules twice make it better? --Paul Hoffman, Director --Internet Mail Consortium
Re: A modest proposal - allow the ID repository to hold xml
At 10:47 AM -0700 9/2/03, Eliot Lear wrote: I don't know about about you, Paul, but I'm writing my drafts using EMACS and Marshall's tool. That allows for generation of HTML, NROFF, and text. The HTML allows for hyperlinks, which is REALLY nice. Great! Why does that mean that the XML input should be published in the Internet Drafts directory along with the text output? --Paul Hoffman, Director --Internet Mail Consortium
Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
At 10:26 PM -0700 6/21/03, Alex Zinin wrote: Folks- Having watched this discussion, it seems a couple of data points might be helpful: 1. L2VPN and L3VPN proposed WGs are part of PPVPN WG split Creation of L2VPN and L3VPN WG does not represent addition of new work to the IETF. They are created as part of the process of splitting the PPVPN WG to improve progress and focus it by setting clear directions in the charters. 2. L2VPN work is already chartered within the IETF The discussion about whether this work should be chartered or not happened when the PPVPN WG was being created. Please see minutes and slides from the PPVPN BOF at IETF 49. L2VPN solutions are within the PPVPN charter and milestones. Hope this helps. My comments about possibly moving this work to a different standards body is based on our track record with this work so far in the IETF, not a worry about new work. Just because we chartered some work doesn't mean we shouldn't revisit the question of whether or not doing so was a good idea, particularly after we see the kind of progress that has been made and the problems that have come up under those charters. --Paul Hoffman, Director --Internet Mail Consortium
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
At 1:31 PM -0700 6/18/03, Vach Kompella wrote: - the IETF's track record for this work so far is quite poor That's not a problem of the ppvpn group only. It is a problem of the IETF. Generally agree. I don't need to refresh your memory about IPSec, do I? SKIP, Skeme, Oakley, IKE. AH or ESP with auth? 5 years of bloody fighting. I'm not sure how to argue with the statement the IETF has done a horrible job with a similar working group, so we want our working group in the IETF. First off, I agree with you about the IPsec WG, and think it is a very good indicator of what the IETF does poorly, particularly in the area of focus. (Hint: look at the number of WG Internet Drafts there are right now in IPsec that no one is working on.) The problems in the IPsec WG and others are typical of the problems of the WGs that are working on trusted VPN technologies. It's wherever the action is that the political jostling for position is the most prominent. That's also where the leadership needs to be strong and participants need to have a nose to the grindstone attitude. That's hardly an indication that the work should not be chartered or worked upon. Er, yes it is. There is no indication that we will do a better job than the terrible job we are doing now. What you propose sounds like we're terrible parents for our six children and barely have enough time to pay attention to them, but maybe we'll be better with the seventh. We have not shown any ability to create standards in this area with due speed or predictability. We have not shown the good judgement needed to limit the scope of the work we do. (Look at the number of L2VPN-based Working Group drafts in PWE3 and PPVPN, much less the large number of non-WG documents being actively discussed. Do you think the new L2VPN charter addresses these concerns of scoping? How about the timelines? Basically, it's going to be a WG issue, chairs and participants, to finish the WG charter items first. Why do you think that the re-chartered WG will have any more luck with these than the current one? There are a zillion hardware vendors and service providers who have reasons to want the dozens of documents that are in the current WGs, and it takes very little effort on their part to promote their views. The IETF structure does poorly in such an environment; maybe a different standards body would do better. The IETF understands the need for layer 2 technologies for OAM much better than we understand the Internet customer's need (or even concern) for layer 2 transport of their IP packets. This is because we have a tighter relationship with operators than we do with Internet users, and because Internet users generally could care less about how their ISPs move their traffic as long as they meet the service level agreements. The ISPs would love to have better cross-vendor interop for the L2VPN technologies, but so far the vendors haven't had time to think about that because they have been overloaded with the literally dozens of flavors that are being discussed in the IETF. Are you talking PWE3 or L2VPN? Yes. There is a significant amount of spillage between the two. The gazillion drafts is in PWE3. The interop issues are localized to the drafts with contention, silly issues of where bits should go. There are 16 pseudowire types: 0x0001 Frame Relay DLCI 0x0002 ATM AAL5 SDU VCC transport 0x0003 ATM transparent cell transport 0x0004 Ethernet Tagged Mode 0x0005 Ethernet 0x0006 HDLC 0x0007 PPP 0x0008 SONET/SDH Circuit Emulation Service Over MPLS (CEM) [8] 0x0009 ATM n-to-one VCC cell transport 0x000A ATM n-to-one VPC cell transport 0x000B IP Layer2 Transport 0x000C ATM one-to-one VCC Cell Mode 0x000D ATM one-to-one VPC Cell Mode 0x000E ATM AAL5 PDU VCC transport 0x000F Frame-Relay Port mode 0x0010 SONET/SDH Circuit Emulation over Packet (CEP) At least half of these are and have been interoperable. It is the harder (and more arcane, IMHO) PW types that people are having a hard time coming to some sort of compromise. And why should the IETF care at all about these? There are other fora for layer-2 interworking. BTW, I'm glad to see you have a healthier respect for providers than Kurtis who claims that most of these providers have bought what their vendor told them to buy. He and I might both be right. In my talks with service providers, I find that many of them who want to expand their presence in, or just get into, the IP VPN market look at what hardware they have on hand in their core (they certainly can't buy any significant new hardware these days) and base their decision on the layer-2 technologies on that. Usually, the customers don't know or care. If the customers care, they only care enough to ask are you using MPLS
RE: WG review: Layer 2 Virtual Private Networks (l2vpn)
At 6:43 PM -0700 6/18/03, Vach Kompella wrote: I'm not sure how to argue with the statement the IETF has done a horrible job with a similar working group, so we want our working group in the IETF. Well, how about, we can't agree on IPv6 numbering schemes, so let's find another standards org to fix that problem. We can't decide whether site-local is good for IPv6 or not, so let's find another standards org. IPv6 is an IP technology. We are supposed to know how to make it work. L2VPNs (and half of the interesting parts of 2547bis L2VPNs) are outside the scope of our expertise. ... What kind of unmitigated disaster would IKE have been if we had just punted it over to, say, the ITU? Worse, no doubt. But I'm not proposing to send the L2VPN work to an organization with no expertise or credibility in the L2 area. Alternatively, we can own up that it is OUR problem, i.e., the IETF, and if we want a solution, we will create one here. If we decide that the problem is one in our realm, I fully agree. But transporting layer 2 stuff over IP is not a problem that affects the Internet. It is a problem for the service providers marketing departments. The past three yeas have proven that service providers can satisfy their customers needs with L3VPNs, with somewhat-interoperable L2VPNs, with non-interoperable L2VPNs, and with just plain layer 2 circuits. What is the problem that the IETF needs to standardize? E.g., I'm happier having IPSec than no security. Of course. But we'd both be happier if IPsec worked better as a VPN technology, and applications folks would be happier if it worked better as an application security technology. --Paul Hoffman, Director --Internet Mail Consortium
Re: CLOSE ASRG NOW IT HAS FAILED
At 11:27 AM -0600 6/16/03, Vernon Schryver wrote: All contributions that are rejected by any moderators (including spam filters) of any IRTF or IETF mailing lists must be archived and should be published on web pages somewhere. FWIW, some of the IETF WG mailing lists that IMC runs get 10 spams a day, and often get the virus/trojans that are 120K each. This is not an insignificant amount of junk to wade through when looking for proof of moderator badness/goodness. And there's also the problem of robots that harvest everything, regardless of your robots.txt file. If we had a system like you describe, it would be believable that the archives would get a fair number of hits from people searching for pr0n but finding our archive of spam instead. I think that having all bounces (for whatever reason) archived is fine; I think having it as web pages somewhere is overkill. Access to one of the big text archives can be a trivial password given to anyone who wants it for research purposes. --Paul Hoffman, Director --Internet Mail Consortium
Re: The utilitiy of IP is at stake here
At 4:12 PM -0700 5/30/03, Dave Crocker wrote: Perhaps you could synthesize the numbers in a way that the carriers will agree to? That it, sanitize out the competitive information, to produce something relevant only to spam control in the aggregate. The numbers are a few years old, anecdotal (although at least they came from people inside the companies!), and not computed in the saw way. For instance, BigISP1 counted the time spent on customer service on spam-related topics plus sysop time plus connectivity costs, while BigISP2 only counted the latter two. But, to be more relevant, let me say that all of the numbers were in millions of dollars. To bludgeon the point a bit: - Big ISPs and other mail service providers know how much spam is costing them. - For some ISPs, the amount is in the millions of dollars. - Even an expensive team of consultants could devise a trust-based or work-based protocol and shepherd it through the IETF for less than one tenth the annual cost for a single ISP. Given the above, the reason that the people who are most financially hurt by the spam problem have not done anything about it from a protocol level is either that they are financially stupid or that their research into the solutions didn't result in a solution that would cost them more. I believe it is the latter. People outside those companies might have different opinions, but to say if we invent a protocol that we think will work, they will use it is nonsense. --Paul Hoffman, Director --Internet Mail Consortium
Re: The utilitiy of IP is at stake here
At 11:36 PM -0700 5/29/03, Dave Crocker wrote: The POP-IMAP example is excellent, since it really demonstrates my point. IMAP is rather popular in some local area network environments. However it's long history has failed utterly to seriously displace POP on a global scale. Exactly right. The benefits of IMAP are obvious to everyone who has looked at it in any depth, and yet it is very thinly deployed. The main reason: the perceived additional administrative overhead. EAH Large-scale mail carriers would probably switch quickly if EAH the accountability feature proved useful, and now we are back to hypothesizing about the behaviors of mega-corporations with massive installed bases and a rather poor history of adopting changes from the IETF community. So far on this thread, we have heard from none of the large-scale mail carriers, although we have heard that the spam problem is costing them millions of dollars a year. That should be a clue to the IETF list. If there is a problem that is affecting a company to the tune of millions of dollars a year, and that company thinks that the problem could be solved, they would spend that much money to solve it. Please note that they aren't. I have spoken to some of these heavily-affected companies (instead of just hypothesizing about them). Their answers were all the same: they don't believe the problem is solvable for the amount of money that they are losing. They would love to solve the spam problem: not only would doing so save them money, it would get them new income. Some estimate this potential income to be hundreds of millions of dollars a year, much more than they are losing on spam. But they believe that the overhead of the needed trust system, and the cost of losing mail that didn't go through the trust system, is simply too high. You might disagree with them, and based on that disagreement you might write a protocol. But don't do so saying the big carriers will want this without much more concrete evidence as to their desires. --Paul Hoffman, Director --Internet Mail Consortium
Re: The utilitiy of IP is at stake here
At 10:40 AM -0700 5/30/03, Peter Deutsch wrote: Paul Hoffman / IMC wrote: ... So far on this thread, we have heard from none of the large-scale mail carriers, although we have heard that the spam problem is costing them millions of dollars a year. That should be a clue to the IETF list. If there is a problem that is affecting a company to the tune of millions of dollars a year, and that company thinks that the problem could be solved, they would spend that much money to solve it. Please note that they aren't. Well, perhaps it's more accurate to say if they thought it could be solved by working with all those nice and entusiastic folks on the IETF general discussion list... ;-) We disagree here. For the millions of dollars that they are losing, they would come up with the solution with the IETF or not. They haven't. I have spoken to some of these heavily-affected companies (instead of just hypothesizing about them). Their answers were all the same: they don't believe the problem is solvable for the amount of money that they are losing. They would love to solve the spam problem: not only would doing so save them money, it would get them new income. Some estimate this potential income to be hundreds of millions of dollars a year, much more than they are losing on spam. But they believe that the overhead of the needed trust system, and the cost of losing mail that didn't go through the trust system, is simply too high. You might disagree with them, and based on that disagreement you might write a protocol. But don't do so saying the big carriers will want this without much more concrete evidence as to their desires. Paul, are you aware of any concrete numbers here? Yes. I've looked through the IMC site, but the only references to cost seem to be in a report from the late 90's, with no hard data. If not, this might be something the IMC could consider pulling together? I'd agree that there's way too much hand-waving going on here on this point... All my discussions were not for attribution. Large mail carriers don't want their competitors to know how many users they actually have (as compared to the highly inflated numbers that various analysts say they have), and they certainly don't want their competitors knowing how much they are spending on dealing with spam. Our company spends more per user on fighting spam than OtherBigCarrier! In aggregate, then numbers were in the tens of millions of dollars US, and that was more than two years ago. I would be shocked if the numbers were much lower now, given the greatly increasing amount of spam and the level-or-increasing number of customers. Again, the summary is that these folks are hurting badly enough to throw highly-qualified full-time staff on the problem, and they don't believe any of the solutions that have been presented so far will save them enough money. If they thought differently, they would have deployed them by now so that they could save those millions of dollars. --Paul Hoffman, Director --Internet Mail Consortium
RE: The utilitiy of IP is at stake here
At 11:09 AM -0700 5/30/03, Tony Hain wrote: Paul Hoffman wrote: So far on this thread, we have heard from none of the large-scale mail carriers, although we have heard that the spam problem is costing them millions of dollars a year. That should be a clue to the IETF list. If there is a problem that is affecting a company to the tune of millions of dollars a year, and that company thinks that the problem could be solved, they would spend that much money to solve it. Please note that they aren't. And that would be because they can't do it in isolation. They need a system wide standard everyone is building to, to make your argument below about cost of untrusted mail moot. And you believe that these companies are so stupid that when they have a problem that is costing them tens of millions of dollars a year, they wouldn't think of coming together for a solution? Maybe I have a higher opinion of them than you do because they were members of my consortium. All of these companies have people following (and often participating) in the IETF. To assume otherwise without first asking them is pretty silly. --Paul Hoffman, Director --Internet Mail Consortium
Re: The utilitiy of IP is at stake here
At 2:22 PM -0700 5/29/03, Eliot Lear wrote: Please indicate some historical basis for moving an installed base of users on this kind of scale and for this kind of reason. History is replete with examples. From the Internet Worm to Code Red, consumers do install software when they perceive either a threat or a benefit. Tony's proposal is not for new software: it is for software that *replaces* what they have now. Further, it is not a one-to-one replacement. It requires new administrative actions by the sysadmin and by the user to validate who they want to get mail from. Getting rid of spam is a HUGE benefit. And all the proposals so far have some amount of cost. The trick is to come up with a solution whose benefit to at least half of the 100 million mail users overwhelms the cost. That is, the bother of using the new system has to be less than the bother of getting spam. Heck. What I've found so amusing is that people seem to upgrade their Microsoft systems just 'cause, with no perceived benefit, but merely protecting from Bit Rot. This is because (despite history) people believe that the replacement will be no harder to user than the previous version. --Paul Hoffman, Director --Internet Mail Consortium
RE: The utilitiy of IP is at stake here
At 4:58 PM -0700 5/29/03, Tony Hain wrote: The sysadmin effort would be setting up an automated way to hand out keys, and the user would have a one-time (or very infrequently) effort to establish a key pair. And you are saying that is trivial? How would a typical user know which third parties to trust? How would the typical user know what to do when they started getting spam through this filter? How would the typical user know what to do when someone wants to send him/her mail but can't because the sender isn't in the right trust group? If you have already worked this out and I missed it, my apologies. A pointer to that document would be very helpful. --Paul Hoffman, Director --Internet Mail Consortium
RE: spam
At 11:36 AM -0700 5/28/03, Tony Hain wrote: The external mechanisms already exist to deal with the social engineering once the originator can be pinned down. This is good to hear. I thought that the international trusted micropayments that would be needed for such a sender-pays system was a problem that was yet to be solved. --Paul Hoffman, Director --Internet Mail Consortium
RE: [Sip] Eating our own Dog Food...could the IAB and IESG useSIP for conference calls
A modest request: could all the people who think that this is a good place to advertise their company's products and services please reconsider? If you really want to offer your services, send a message to the original proposer, not the whole mailing list. Advertising here is really, really tacky. --Paul Hoffman, Director --Internet Mail Consortium
Re: Barrel-bottom scraping
At 12:05 AM +0200 3/24/03, Pekka Savola wrote: I fail to see what added value they might bring They could be very useful to explaining to our management and marketing departments and so on the value of standards, particularly IETF standards. Further, because most companies focus on a small part of the Internet, they could show why the whole picture is important. And I agree that they should not be held next to IETF meetings. Maybe once a year between meetings, or in conjunction with other networking events that these people might go to, such as N+I or Comnet. --Paul Hoffman, Director --Internet Mail Consortium
Can we move this discussion to a more appropriate place? (was:Re: IAB policy on anti-spam mechanisms?)
This thread is trying to redefine or redesign SMTP's use of TLS. It should probably be happening on the [EMAIL PROTECTED] list instead of the main IETF mailing list. That's where the implementers are, and that's where the implementers of most of the foo-over-TLS protocols are. They too should be hearing this discussion, since much of it applies to many protocols, not just SMTP. --Paul Hoffman, Director --Internet Mail Consortium
Re: IAB policy on anti-spam mechanisms?
At 5:34 PM -0800 2/27/03, [EMAIL PROTECTED] wrote: Your question assumes that the DUL is actually a meaningful anti-spam mechanism. It is not. Could you elaborate a bit on what you mean by meaningful? As someone who uses the DUL list as an anti-spam mechanism and who experiments with turning it off and on, I can definitely say that turning it on reduces the amount of spam I receive (on the order of about 100 messages a day). I recognize that it also harms folks like you for many of the reasons you give. But I don't understand why you say it is not a meaningful anti-spam mechanism. --Paul Hoffman, Director --Internet Mail Consortium
RE: a personal opinion on what to do about the sub-ip area
At 4:50 PM -0800 12/9/02, Tony Hain wrote: If there were are real need for cross group coordination within the sub-IP area, that would be a little clearer. A presentation at the SubIP Area meeting in Atlanta drove home the point that the amount of coordination in the area was not as high as expected when the area started. The originally-envisioned hourglass (with CCAMP in the middle) turned into spaghetti. This is not to say that the spaghetti is bad, just that the proposed coordination didn't help keep them on track and therefore might be less needed than some are saying. --Paul Hoffman, Director --Internet Mail Consortium
Re: mail headers for announce
ahem Or the IETF could simply start using its own Proposed Standard mechanism described in RFC 2919. --Paul Hoffman, Director --Internet Mail Consortium
[idn] Re: CDNC Final Comments on Last call of IDN drafts
At 12:52 PM +0200 6/6/02, Simon Josefsson wrote: This means IDN is not guaranteed to be secure on non-Unicode systems. There are alot of non-Unicode systems out there today... Nothing is ever guaranteed to be secure. Even if we supplied mapping tables, there is no guarantee that the mapping tables we supplied would match those already in use in those systems, so there will be the same security issues. In fact, we can be sure that some standardized mapping tables would disagree with those already implemented. When standards bodies for character sets define such equivalences, and when those equivalences gain popularity, it might be appropriate for the IDN effort to consider incorporating these new standards. This isn't an adequate solution IMHO, when the consequences of errors made by such standard bodies, or conflicts between different standard bodies, or different interpretations of said standards, or changes between different versions of those standards, or simply a complete lack of standardisation in the area (which is the situation today), may be exploitable for attacking systems on the Internet. And your proposal for an adequate solution is? Short of forcing every current system to use a single set of standardized mapping table (which is patently unrealistic), how could you ever avoid such an exploit? Further, the exploit you descirbe is identical in every application that allows an encoding of the Unicode character set (such as UTF-8). Are you saying that we shouldn't allow any input in UTF-8 in any application until there is both a standard set of mapping tables and absolute conformance to them? --Paul Hoffman, Director --Internet Mail Consortium
Re: [idn] WG last call summary
At 3:58 AM + 3/11/02, D. J. Bernstein wrote: You say that you are obliged to ignore all these objections because the IDN WG has to _do something_. You are lying again, Dan. Marc never said that, and you know it. --Paul Hoffman, Director --Internet Mail Consortium
Re: RFC2119 Keywords
At 8:15 AM -0500 2/15/02, Scott Brim wrote: In normative text, I don't see how must could occur anywhere except where it was supposed to mean MUST. It occurs when describing how something happened, not what needs to happen. Example from a current Internet Draft that is having the capitalization fixed: ...not less than 3, but 4 is less than 5, so 4 must be the last digit. - ...not less than 3, but 4 is less than 5, so 4 has to be the last digit. There were a few places where the must turned into a MUST as a way of specifying how an implementation of the protocol had to work. --Paul Hoffman, Director --Internet Mail Consortium
Re: REMINDER: revision to RFC2727 - NOMCOM
At 8:50 AM -0800 1/25/02, Dave Crocker wrote: At 10:34 AM 1/25/2002 -0500, James M Galvin wrote: I just wanted to call your attention to the recently announced proposed revision: Perhaps the best time for pursuing revisions to this document is immediately after the nomcom has done it job. That way you will have a pool of very fresh suggestions to work from. (and this suggestion is coming from someone on the current nomcom who is explicitly offering to participate on that basis, but also feels that it would not be appropriate to participate in the middle of the major nomcom deliberations.) As someone who was on a previous nomcom, I fully agree with Dave. It would have been silly to think about this while in the midst of deliberations that could affect what I said. --Paul Hoffman, Director --Internet Mail Consortium
Re: one copy sent to list but THREE returned
At 5:11 PM -0500 1/6/02, Gordon Cook wrote: I sent but a single copy of 'empowering' to the list. It returned THREE to me. If everyone else got 3, my apologies. If anyone can inform me as to what happened i'd appreciate it. Er, a better question is why you spammed the IETF list at all. --Paul Hoffman, Director --Internet Mail Consortium
Re: Splitting the IETF-Announce list?
At 4:02 PM -0600 11/13/01, Pete Resnick wrote: I am interested in getting all of the posts to the IETF-Announce list *except* for the greatest bulk of those posts: Internet Draft announcements. I find it hard to believe that I am the only one who would prefer if the I-D announcements were on a separate mailing list. Would it be possible to implement this? If I am correct and there are an awful lot of people who are uninterested in I-D announcements, Pete, you really should get a mail client that has an easy-to-use filtering interface. :-) it would cut down on outgoing mail of the secretariat substantially. Ah, that might be a consideration. Unless it turns out that the secretariat's Internet connection bills are high, it seems worthwhile to keep the lists merged. To many of us, seeing the names and titles of new -00 drafts is as interesting as seeing RFC announcements. Further, waiting until a draft is in IETF Last Call before people notice it is not a good way to create protocols. --Paul Hoffman, Director --Internet Mail Consortium
Re: participation in IETF meetings
Going back to the original question about more multicast sessions: The advantage of multicast vs. tape-and-archive is the real-time aspect for the viewer. However, this is rarely, rarely used. If it turns out that switching from multicast to tape-and-archive can get more camera operators in more rooms, that would be a win for more WGs. --Paul Hoffman, Director --Internet Mail Consortium
Re: Last Call: PIC, A Pre-IKE Credential Provisioning Protocol toProposed Standard
At 3:56 PM -0400 10/11/01, Darren Dukes wrote: This may be nit-picking but I have seen no mention on IPSRA, or any other list, or during any meetings that there are two interoperating independent implementations of this draft. Is anyone able to confirm that implementations exist and interoperate? Yes, it is nitpicking. This call is for PIC to go to *Proposed* Standard. The requirement for two interoperable implementations is for going to *Draft* Standard, which is the step after Proposed Standard. See RFC 2026 for the not-so-gory details. --Paul Hoffman, Director --Internet Mail Consortium
Re: why cant this list clean up the spam!!??
If this list cleaned up the spam, how would we receive all your unsolicited advertisements for your newsletter? I wouldn't want to prevent IETF list subscribers from having the chance of getting important Internet insight from someone who can't tell the difference between a virus/worm and spam. it is enough to make me consider subscribing to the censored list... I don't subscribe to that list: do they pass along your ads? If so, it won't fix your spam problem. --Paul Hoffman, Director --Internet Mail Consortium
Re: OPES charter proposal again.
At 2:45 AM +0100 7/3/01, Lloyd Wood wrote: I do like the 'extend [..] the iCAP protocol without being obliged to retain any level of compatibility with the current iCAP proposal.' Fine, since iCAP's just an individual draft -- but isn't extending without being compatible something only Microsoft is generally regarded as being capable of doing? No, we have done it with SSL-TLS, S/MIMEv2-S/MIMEv3, PGPorig-OpenPGP, vCalendar-iCalendar, and so on. --Paul Hoffman, Director --Internet Mail Consortium
Re: too many Out of Office AutoReply
At 9:30 AM -0400 6/29/01, Steven M. Bellovin wrote: But I'm disturbed that Exchange is using the Precedence: line as its selector mechanism. I'm hardly an email expert, but a quick grep through the RFCs turned up exactly one mention of the Precedence: header line. That reference is in 2076, which describes it as Non-standard, controversial, discouraged. No RFC definition is cited. It would be nice if such an important feature relied only on standardized headers. Steve, we'll forgive you for not being an email expert. If you were one, you would know that this topic, and half a dozen of related meta-topics, have been beaten to death in the (finally dead!) DRUMS WG, and on the ietf-822 mailing list in the past six or seven years. A summary is that some implementations prefer to be strictly standards-compliant but piss off their users by not doing enough, while others choose to do things the users want even though it doesn't go strictly by the standards. In this case, there are non-standard headers in common use that give valuable heuristics to programs, and no standard ones that give the same information. Many companies, apparently including Microsoft, use that non-standard information. --Paul Hoffman, Director --Internet Mail Consortium
Re: since drums is closed...
At 12:00 PM -0500 5/22/01, Chip Rosenthal wrote: On Tue, May 22, 2001 at 05:00:49PM +0200, Maurizio Codogno wrote: I hope someone may give me an answer here, even if the topic is not quite in topic for the list. Don't have an answer to your question, but thought I'd point out that most of the DRUMS participants have moved over to the ietf-822 mailing list hosted at imc.org. The folks who want to talk about message formats have moved there. The folks who want to talk about message transport have moved to ietf-smtp. DRUMS was covering two different topics. IIRC [EMAIL PROTECTED] should work. Yup, and [EMAIL PROTECTED] will get you the companion list. --Paul Hoffman, Director --Internet Mail Consortium
Re: Mailing list policy
At 4:54 PM -0400 5/20/01, Perry E. Metzger wrote: When you are the maintainer of a list That assumes that someone is the maintainer of the IETF mailing list. At this moment, that is not the case. You are asking that an additional task be put on one of the IETF Secretariat folks. That's a reasonable request (and one that I would second), but it is not based in current reality. Quite a few IETFers have more than one email address. Which is why Majordomo lets you have a seperate list of addresses that can post but don't get the mail. Works beautifully. No, it works clumsily. It requires that someone who wants to post from a different address than the one they are subscribed to must somehow register the alternate address with the list maintainer. Or that the list maintainer must write custom software that enhances the list of allowed-to-post addresses with guesses like if there is a subscription for [EMAIL PROTECTED], also allow [EMAIL PROTECTED]; if there is a subscription for [EMAIL PROTECTED], also allow [EMAIL PROTECTED]. But that will still miss people who are subscribed from [EMAIL PROTECTED] but posting from [EMAIL PROTECTED] (And, yes, I've written such code for the lists IMC and VPNC runs; it is available on request.) --Paul Hoffman, Director --Internet Mail Consortium
Re: Deja Vu
At 12:52 PM -0500 3/22/01, William Allen Simpson wrote: None of the Mac folks I've talked to have had any success with the wireless DHCP. We have to hand configure. You must run in a different circle of IETF Mac users. None of the many that I know (including me) had any problem. --Paul Hoffman, Director --Internet Mail Consortium
Re: Blast from the past
At 10:30 PM -0500 1/24/01, J. Noel Chiappa wrote: PS: Those of you with sharp eyes will notice that everything has a class A address! ...and that some of those addresses still work, and appear to be used by folks directly related to the original owners. If only URLs could be so persistent... --Paul Hoffman, Director --Internet Mail Consortium
Re: Again: Number of Firewall/NAT Users
At 12:10 PM -0500 1/23/01, Frank Solensky wrote: One could ask a sample of administrators and extrapolate the results but, again, the problem becomes how confident you could be of the results if you don't get a very significant response rate The problem is *much* worse than that. You have to be confident that your sampling method actually reflects enough of the Internet to be valid. Determining how you have reached a valid sample of administrators would be an interesting problem. Further, it is safe to assume that administrators for the largest networks are the least likely to reply, or to reply accurately. And then there is the problem of assuming that they understand your question, and can even count the systems on their networks well enough to answer accurately... --Paul Hoffman, Director --Internet Mail Consortium
Re: internet voting -- ICANN, SmartInitiatives, etc.
Ed, why do you insist on advertising your patent-pending voting solution on the IETF mailing list? It does not involve any IETF protocol work, does it? --Paul Hoffman, Director --Internet Mail Consortium
RE: IETF logistics
At 9:44 AM -0800 12/20/00, Christian Huitema wrote: I have a simpler point about logistics. What we are doing in the IETF nowadays is downright dangerous. Prevalence of the laptops means that the room is criss-crossed with power cables. Lack of room means that the alleys are packed with standing or sitting listeners. If anything goes wrong and we have to evacuate a room, we are in for the headlines. In fact, if we continue breaking the fire code in every room of every meeting, this outcome is almost guaranteed. "Every room"? "Every meeting"? This hyperbole is not justified. It happened in some of the meetings, but not others. And, in some of those overcrowded meetings, Steve Coya came in and made some of us leave so that the aisle was clear. --Paul Hoffman, Director --Internet Mail Consortium
Re: Bottom feeders
At 1:54 PM -0600 12/20/00, Brian E Carpenter wrote: Hard to say, but the newcomer's briefing and the Tao of the IETF are both on the web site. It is important to note that the Tao is being substantially upgraded and has lots of new material specifically aimed at dealing with some of the problems discussed on this thread. Look for a revised version of the draft in the near future. --Paul Hoffman, Director --Internet Mail Consortium
RE: IETF logistics
Just to be clear, Pete's idea does not preclude giving newcomers to the meeting context. Instead of the 5 minutes for agenda bashing and then straight into presentations, the WG chair can spend 15 minutes saying what the group is doing, where the WG is and is not meeting its charter, and the status of the drafts in front of the group. At that point, viewers (as compared to participants) will know better whether or not they want to stay and will also have some idea of why the agenda looks like it does. --Paul Hoffman, Director --Internet Mail Consortium
Re: Congestion control
WG chair says "OK, the room is now over-full. Who are there people in the doorway or outside who intend to work actively on drafts or forming the charter for this group? I see seven hands up. Could fourteen people who are currently sitting or jammed up against a wall who do *not* already plan to work actively on drafts or forming the charter for this group please be polite and leave? I will announce the mailing list address for this BOF on [EMAIL PROTECTED] if we get anywhere during this hour. Also, look for an announcement of a Bar BOF on the messages board later today. OK, about ten people have left. Thanks!" This, of course, relies on the early sitters being polite and patient, but that has been known to happen at various times in IETF history. --Paul Hoffman, Director --Internet Mail Consortium
Re: Postel's razor applied to ACE
One more time with feeling: please take this discussion to the IDN WG's mailing list. It has no place on the main IETF mailing list, and it needs to be discussed where the people working on the protocol are working. Of course, one might want to read the WG's archive before posting to the list, given that many of the topics that have appeared here this week have already been discussed. IDN WG info: http://www.i-d-n.net/ --Paul Hoffman, Director --Internet Mail Consortium
Re: Diacritical application in the DNS
At 7:06 PM -0500 12/5/00, Dan Kolis wrote: Now we are getting down to the nuts and bolts No, we're not. This is a long re-hash of unfinished discussions happening in the IDN Working Group. As was requested earlier in this thread, please go read the archives of the IDN WG, and if you have something to say, say it there. The archives and all the drafts are at http://www.i-d-n.net/. --Paul Hoffman, Director --Internet Mail Consortium
Re: Bake-off as trademark
OK, we have now reached 20 messages from armchair lawyers on trademark law. Given the earlier threads this year from armchair lawyers on patents, that leaves us just two months for us to have a ponderous thread on trade secrets, and we will have covered the main parts of intellectual property law. For 2001, I propose that we have at least one long thread with our expert opinions on international law, given that the IETF is a global community. --Paul Hoffman, Director --Internet Mail Consortium
RE: can vpn's extended to mobility
At 2:19 PM -0700 9/26/00, Dave Crocker wrote: At 07:56 PM 9/26/00 +0100, Lloyd Wood wrote: Beg to differ. Encapsulation makes the VPN virtual. Encryption ensures that the VPN is private. All networks are privately managed, whether virtual or not; referring to that explicitly seems a bit pointless to me... while your explanation is entirely logical and reasonable, it does not match the actual history of the term. The "actual history" is not what is important here; what the "actual customers" expect is important. We are seeing more an more ISPs offering VPNs, some using IPsec, some not. the term vpn has always been independent use of encryption. That was true up to about three years ago, but it shifted when IPsec became widely deployed. VPN-as-frame-relay pretty much fell out of the public mind. Now some ISPs are trying to resurrect the old "private management" definition because it is much cheaper for them than to offer actual privacy. historically there was -- and pretty much still is -- a distinction between public (open) and private networks. When the network runs on top of another network, rather than using its own wires, it is called virtual. hence the composed term "virtual private". This sounds a whole lot closer to Steve Kent's "virtually private". It makes sense in the old "we own the wires" world, but not in today's "we care about someone seeing our data" world. --Paul Hoffman, Director --Internet Mail Consortium
Interesting article on patents and standards
A recent editorial in Microprocessor Report (a pricey but very useful newsletter) covers an interesting patent tussle in the RAM market. It is relevant to the IETF process in that the features that were patented were put into the standards process while the patent owner silently moved the patent forwards, something we have seen here. The editorial, titled "Ethical Standards", can be found at http://www.mpronline.com/mpr_public/editorials/edit14_17.html. --Paul Hoffman, Director --Internet Mail Consortium
RE: rfc-editor?
At 04:46 PM 4/14/00 +, Bob Braden wrote: There IS no dark conspiracy here, just people devoting CONSIDERABLE time and energy (without stock options, I might add) to making the internet work. A great idea! Stock options in the RFC Editor function! - A hot startup of about 25 years (in real time, not Internet time) - Geekier than Slashdot - Can change the definition of the Internet by themselves overnight - Content is created for them by industry leaders for free - Just look at the demographics of the people who come to their "standards portal" - Imagine how much Cisco or Microsoft would spend to buy them
Re: Device upload for all platforms -- the official HTML WG position
Why is this thread being run on the IETF mailing list? The IETF handed off responsibility for HTML to the W3C long ago. If the reason is to show people that someone has a beef with the way that the W3C is handling HTML, that point has been made. (I can already picture certain IETF folks starting to deluge W3C mailing lists when IAB appeals don't go their way...) --Paul Hoffman, Director --Internet Mail Consortium
