Re: All these discussions about meeting venues
I ran into another participant on the bus one day who told me he used the bus to go and get lunch every day rather than hanging around the MECC. He had plenty of time, he said, in the 1.5 hours. This was, alas, on Thursday or Friday, so I didn't try it myself. Given the time it took me to get to my hotel, and the five or six restaurants I spied immediately around it, I suspect it would have worked. I'm finding the complaints about the remoteness of the venue in Maastricht to be contrary to my own experience, but I didn't arrive late due to a delayed flight and I didn't have to get back to the MECC area in the evening. It is beginning to sound like the real fault with the Maastricht venue was that people were not fully briefed on how to handle it. As Dave Crocker said, when meetings are held repeatedly in one location, people learn what works, where to find things, etc. It becomes a familiar place. Perhaps some additional effort needs to be made to provide guidance to attendees so that, for instance, everyone attending a Maastricht event knows that there is a free bus pass, it is 5 minutes to a choice of restaurants, someone has tested it during the lunch break hours and it is an easy round trip without being late, and so on. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: All these discussions about meeting venues
I give up. We obviously speak different version of English. This is correct. When you see bus you think of a pleasant safe clean vehicle that arrives every 5 to 10 minutes, and efficiently takes you to any part of the city that you need. When an American sees bus they think of an unpleasant dangerous dirty smelly vehicle filled with poor people and teenagers carrying knives that takes 60 minutes to arrive even though the schedule promises a bus every 30 minutes and which only goes to useful places like hospitals, unemployment office, and dirty smelly dangerous poorly lit bus stations.# Any unfamiliar venue is foreign to attendees, even within their own country. The only way to make an unfamiliar venue seem unforeign is to explain how things work there. The complaints that come after every meeting follow a pattern. This pattern identifies which things people find problematic in foreign venues. I believe that the IETF could reduce the frequency of such problems by ensuring that these issues are all explicitly covered in a venue guide prepared with the assistance of the host and other local people. This guide should be available in advance of the meeting, roughly the number of week in advance when people start asking questions on the list about trains, taxis with English speaking drivers and so on. And it would not hurt to survey all attendees of the meetings, ask if there are any complaints, and then when the guide is ready, send it to all the complainers and ask them if they believe the guide would prevent a recurrence of their particular issue. Also note that even familiar venues can change, fantastic restaurants can turn into striptease bars, the local red light district can shift to a different street, the kosher supermarket could be bought by an Egyptian family and turn into a halal market. And new attendees do pop up from time to time. Even a familiar venue can benefit from a guide. Since yours is native I am obviously in the wrong. On this I disagree. English is a difficult language for natives to speak because most of them lack the understanding of other languages which is necessary to fully comprehend the meaning of a large part of the English vocabulary. When I started using the Internet back in the early 90s I was amazed to find that I could identify native English speakers in a few sentences. Native speakers of English almost always made spelling and grammar mistakes in every second sentence. If someone wrote grammatically correct English they were almost certainly from Northern Europe (Scandinavia, Netherlands, Germany, Austria). Because of this, in the absence of other evidence, I would assume that you are right and the native speaker is not. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: All these discussions about meeting venues
As examples, we have had a significant number of venues in recent years that were distant from major transportation hubs and/or were distant from local resources such as the usual array of hotels, restaurants, markets and the like. Of these I can name only Dublin as falling into the category which you class as a pattern. I am not saying Maastricht or Dublin did not have problems, I am saying the claim that there is a significant pattern here is over-stating it. Please keep in mind that we have several non-negotiable requirements for venue selection. The first is actually availability of venue on our dates since our dates are FIXED. Proposals for changing the meeting model won't necessarily change that reality. Even if you are unwilling to accept these criticisms when CHOOSING venues, what is wrong with applying some bandaids to fix these problems for those venues where it is an issue. Even in Dublin and Maastricht there were restaurant districts nearby for those with vehicles. If the hosts or the IETF had operated a 15 min. shuttle service to the restaurant districts from 12 noon to 12 midnight, that would likely have resolved most if not all of the complaints about restaurants. There really needs to be more creative thinking applied to these problems in addition with local knowledge. For instance in some venues it might be better to make bus guides available to take a group on local transit every 15 minutes rather than having shuttles. Far better to identify all the people who have issues, and then collectively brainstorm ways to mitigate the problem without changing the city and hotel used. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: All these discussions about meeting venues
Even in Dublin and Maastricht there were restaurant districts nearby for those with vehicles. Virtually no attendee had a vehicle ateither of those venues (or many others.) People willing to ride on a bus or pay for a taxi are those with vehicles. The point is that something which is too far away by foot, is probably not too far away if convenient vehicular transport is available. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Wallet theft in Brussels train station
One moment of inattentiveness while putting my roller bag up in the over seating racks on the train from Brussels to Aachen (where I am for a pre-IETF meeting). And they were middle-age men. This is likely a common style of picking pockets. I ran across it in Simferopol, Ukraine upon entering a bus to the coast, at the train station. In this case it was rather obvious because the pair were loitering by the bus and when my wife and I decided to enter, one of them went in the rear door and went forward while the other followed me. I just cursed at them in Russian and they eventually gave up. Thinking it over, even if you are very attentive at watching your surroundings, when boarding transport your attention tends to be fully focused ahead of you and you also expect people to be right behind. Since then, if there is someone behind me on an airplane or train, I put my luggage on the seat, then turn 180 degrees and leave the aisle until it is clear again. Then I go for the overhead bins. You may find this to be a useful protocol as well. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
Sadly, bahn.de seems to have restricted its scope to Europe. Last week I searched for a connection from Oslo to Pyongyang, and bahn.de couldn't show me any. I think there are trains from Vladivostok and/or Beijing, but they're not in the database. Yes, once you get into the former Soviet Union, you are in a totally different rail transport system and you need to use local sites to get your info, and probably buy your tickets via local companies who ask you to fax your credit card info and post you your tickets. http://www.poezda.net/en/index is a good site for checking schedules although it doesn't have all the trains on the edge of the former SU. For instance it couldn't find the Ukrainian train #401 from Praha (Prague) to Lvov when I was recently buying tickets for a trip from London to Krivoy Rog, Ukraine. Also, the station names are in the native languages so Prague is Praha, but interestingly, they don't use Ukrainian names like Lviv preferring the Russian name Lvov instead. Before you buy any tickets, do read up on Russian/ex-SU trains and ticket types because the typical 1st class/2nd class system does not really apply. And make sure you really understand what Platskartny means before you choose that type of sleeper rather than Kupe. In a nutshell, Platskartny cars are like a barracks with bunkbeds, and Kupe or Spalvagon is a car full of sleeper compartments. And Beijing is a major destination for Russian Railways with lots of regular trains from Moscow, so you definitely could get to IETF Beijing that way if you have the time to spare. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Protocol for TCP heartbeats?
I was just interested in whether the behaviour have been defined for those who need early failure detection (systems with failover capabilities) and are willing to pay for the additional bandwidth used (financial sector). Why didn't you say so in the first place? I believe that the common practice is to send two timestamped copies of every packet which are routed over two distinct network paths, i.e. not sharing circuits or routers, and then the receiver waits for both copies to arrive. If the delay between the two identical packets is too large, then the network is at risk, and you should assume the worst, i.e. the information is out of date and should be discarded. The timestamps are there to show you the variation in latency of the first packet in the pair to arrive. A couple of ways of sending two copies via two diverse paths are to use MPLS where you can set up two LSPs over different topological paths.or to use two different multicast trees which are routed differently by your cooperating network provider. Either SFTI or NYSE had published something about this which I downloaded and read about 6 years ago. Can't remember all the details but I remember that the intro talked about the transition from bisync to IP. You really should be asking this kind of question elsewhere where the financial types hang out. Latency is so important that even the guys who are primarily software developers tend to know a lot about how to do this. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The point is to change it: Was: IPv4 depletion makes CNN
to check and see if this device supports multiple IPv4 addresses and 1:1 NAT. Unless I'm missing something, it does not. It does have NATPT, but that's not sufficient. I always cringe when I see such discussions hinging around what an Internet gateway box supports. The word supports is such a weasel word which makes minor imperfections that are easily fixed seem like major problems. What is supported is usually just the set of the features that the manufacturer wants to document and publish. Devices often have unsupported features that work fine so the question of whether or not a feature is supported has more to do with whether technically incompetent people will feel comfortable using it. Instead, I think it is better to look at what features *EXIST* for the platform and what subset of those features are IMPLEMENTED. Many Internet gateway boxes are based on an embedded Linux platform, so just about any IPv6 feature that you can imagine EXISTS and whether or not it is implemented is primarily down to the will of the manufacturer. There was a time when RAM capacity was also a limiting issue but I think that time has passed. Nowadays, if an Internet gateway lacks some feature that is widely implemented on Linux, then it is a minor imperfection that should be easy to fix if only people will COMMUNICATE DIRECTLY WITH THE MANUFACTURER, not through the press and Internet mailing lists. Yes, I am aware that not all Internet gateway boxes are based on Linux, but if that creates a barrier to implementing features like IPv6, then the marketplace can sort out that issue. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
That reminds me: if you intend to use a credit card in electronic contexts (such as buying train tickets at a machine, etc.), you should make sure you know your PIN code. On the way home from Anaheim I helped some guy who had some problems because he wasn't even aware that his card had a PIN code. Not sure if this applies to Americans, but when I lived in Canada, I had a 5 or 6 digit pin code, but internationally, pin codes are only 4 digits. If you have a longer pin code, change it to a 4 digit one before travelling. --Michael Dillon 2 years ago I was back in Canada, visiting, and in a small restaurant, I noticed the familiar chip and pin reader. When I remarked on it, they said it was a new system that was coming in but even the bank didn't know how it worked yet. I said, let me show you and paid for the meal with my UK chip and pin card. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
I have never seen a credit card purchase with PIN. In the UK, all credit card purchases use a PIN with Chip-and-PIN cards except when their network link is down or your card is registered as signature-only. Some elderly and disabled people have the signature-only option, and foreigners too, of course. Debit cards, however, can be used without a PIN in certain circumstances. A few years back, I forgot my PIN code after changing it and promptly spending a month abroad. Back in the UK, I paid at the supermarket with the debit card, and asked for 10 or 20 quid cashback. No PIN, no problems. I think they have changed that now, and my latest debit card came with a notice that it can be used PIN-free for purchases under 10 pounds. This uses the RFID in the card and only works at retailers like Caffe Nero, who have installed the RFID readers. It's basically the same as the Oystercard used for riding the tube, and in fact, many people have a special Oystercard (perhaps with extra RFID) that works in coffeeshops too. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Make HTML and PDF more prominent, was: Re: Why the normative
And if we should change anything about the Author's Address section, then it would be to replace the contact information with URLs to an IETF web server where each author can update/maintain his contact information. If HTML is used to provide that information, then authors could provide their name in their own language and using their own character set (Arabic,Hanzi,Hebrew,Kanji,ISO-Latin-X,whathaveyou) in addition to the US-ASCII representation -- and that would be a I18N use in the sense of rfc2825. In the real world it is common to find business cards that are printed on two sides. One side has everything printed in the Latin alphabet for an international audience, and the other side is printed in Japanese or Russian or Arabic for a local audience. If the IETF did adopt an XML format as the normative one for RFCs it would be possible to have two versions of the author info section, one with US-ASCII representation of names and addresses and the other with Unicode representations of the same. When converting to an HTML or PDF viewable representation, the US-ASCII form could be chosen by default or perhaps the Unicode version could be relegated to an appendix. Artificially creating interop problems in written language, by inserting arbitrary characters from foreign languages into a communication, seems like a very bad idea. However, making those more accurate forms available elsewhere in the communication is a good idea. In the USA, a Japanese person will present their business card to you with the English side up. But in Japan, they present it with the Japanese side up. In all cases, the card contains both representations. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Make HTML and PDF more prominent, was: Re: Why the normative
I suggest that anyone who wants to drag our document formats kicking and screaming into the third millennium might share their résumé with this list or, even better, arrange a meeting at IETF 77. Shall we schedule a soirée at the Anaheim Hilton's Café Del Sol? I gather that this soirée will produce your перестроика manifesto? --Michael Dillon P.S. perestroika = перестроика ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: A state of spin ... presented in ASCII
The idea that Knowledge Representation must occur in English means those that speak it poorly, and many others fail to reach the people who are part of the constituency and as such they fall short of the IETF's capabilities to deliver. They also may actually become victims of the language barrier If we had a normative XML format, that can easily be translated into both viewable and printable HTML, then one could imagine a project to translate all the RFCs into many languages in conjunction with Google Translate. This particular translation tool offers the user the possibility of correcting an inadequate translation. The tool learns from these corrections and therefore the translations of later RFCs would be more accurate even before a human gets involved. This kind of automated translation does not work well with fixed length line paginated text. In other words it works better with text in a flowable format so that formatting is separate from the content itself. And for really stupid things like diagrams which are so critical to have in all technology briefs and that those briefs made out of ASCII characters alone have really bad diagrams generally... XML also offers a standard called SVG for diagrams, which retains the text labels of diagrams in a format which could be processed by automated translation tools like Google Translate. Currently Google translate doesn't process SVG, but the possibility exists unlike with many other image formats. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII
The virtues (or lack thereof) of xml2rfc are a separate discussion. The question isn't how we generate the normative output, but what the normative output should be. Seems to me that this discussion has reached the point at which running code is needed in order to get any further. May I suggest that those interested in changing the normative format come up with an example based on a couple of RFCs, one recent and one ancient. For instance, if you believe that an XML format is the right one, present us with an example RFC in normative XML format along with some XSLT transformations that can be used to produce HTML and ASCII text format versions. PDF shouldn't be an issue since it is easy to change just about anything into a PDF file, but it might be useful to document the workflow and toolchain required to go from normative XML to archival PDF/A since it seems sensible maintain archive copies of all RFCs as well as normative. Note that a PDF/A document could contain an appendix with the source code of the normative XML document, thus archiving that as well. If it can be demonstrated that an XML normative format is workable and can be easily transformed into other needed formats using a variety of common tools, then there is some point in extending the discussion to editing and submission formats. I do believe that one can trivially export a normative XML document into formats suitable for viewing in all the contexts discussed in this and previous threads on the topic. It is therefore trivial for the IETF to offer a download tool for every RFC that allows the user to choose a set of formats and receive a package of files in their choice of .ZIP, .7z, .tar.gz and other formats. Each file would have a copy of the specified RFC in the chosen formats such as HTML, HTML with printable CSS, ASCII text, UNICODE text, specified column width text, paginated or unpaginated text with specified page length, PDF, PDF/A, XML, .doc, .docx, .sdw, .odt, etc... If nobody is willing to produce a sample normative XML format RFC, then let's drop the whole topic. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-dnsext-dnssec-gost
One of the problems with GOST is its lack of availability of documentation/specification and the meaning, purpose and characteristics of algorithm parameters. A bit of Googling turned up this http://vsegost.com/Catalog/96/9658.shtml with scanned GIFs of ГОСТ Р34.10-1994. There is a link to the other one, ГОСТ Р34.10-2001 on that page as well. This does seem to document the parameters. Is the real problem the lack of English language documentation? If so, I'm sure that the people who would like to use these algorithms could arrange for translations of the two documents, and perhaps even make that an individual submission as an Internet draft. Whether and how much the -1994 version is deprecated is also a complete mystery. That may be explained by its use in card payment systems. As you may know if you follow the news, a Cambridge team has just found a HUGE hole in the UK's chip and pin payment system, but a subtext of that announcement is that other weaknesses documented in previous years still have not been fixed. Signature algorithms used in payment systems get embedded in all kinds of devices, and software systems, making it hard to deprecate stuff fast. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: silly legal boilerplate, was Regarding RIM's recent IPR disclosures
A better response would be to send the stupid boilerplate (and only the boilerplate, not the real message, or its headers) to the CEO (or corporate lawyer, or similar) of the organisation that sent the message, along with text something like... I thank an employee of your organisation for the message sent to me. This note is to inform you that I do not accept, and will not cooperate with your organisation's non disclosure request (as shown herein). If you did not intend the information contained in the message to become available to the public, your organisation should not have sent it to me. While I respect your copyright of the message itself, I will use the information I learned from the message to my own advantage, and that of anyone else I feel will be able to profit from its contents. Once again, thanks again for supplying me with this valuable information. and nothing else. A far better strategy would be to pick a law journal or other publication directed at the legal industry, and then send the above in a letter to the editor, prefixed with a question as to whether anyone believes that such disclaimers carry any legal weight. Choose a publication that is in the same legal jurisdiction as the company whose email messages carry the disclaimer. If enough people do that, eventually a few of these letters to the editor will get published, and the whole thing will get more discussion within the legal industry. I suppose it would also work to choose prominent newspapers that are typically read by lawyers, in the USA, New York Times or Washington Post, in the UK, The Times, or The Guardian, in Australia, the Sydney Morning Herald. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The IETF and the SmartGrid
Myself and others are deeply concerned by how this effort is developing. There is no current consensus on what the communications architecture of the SmartGrid is or how IP actually fits into it. The Utility Industry does not understand the current IPv4 number exhaust problem and the consequences of that if they want to put a IP address on every Utility Meter in North America. What is equally troubling is that many of the underlying protocols that utilities wish to deploy are not engineered for IPv6. We have an example of that in a recent ID. I've asked the ARIN Public Policy mailing list how people would feel about banning the Electric Utility industry (and sub contractors) from receiving any IPv4 addresses for use on the Smart Grid. This would include direct ARIN allocations and assignment from ISPs. I think that you are right to raise this issue in discussion since we badly need to shine a light on the details of transitioning the Internet to IPv6. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Local Beijing people response - RE: Request for community guidance on issue concerning a future meeting of the IETF
Some folk say that we should ignore the language in the draft contract, because it will not be enforced, except under extreme circumstances. First, it is never appropriate for people signing a contract to assume that it won't be enforced, especially when they cannot really know the exact conditions that will cause it to be enforced. (The term fiduciary responsibility covers this.) Second, these assurances are coming from people who cannot speak for the hotel or the government. Hence, they are merely guessing. This is true, however there is another path that could be taken. Let the host sign the contract. Then, engage with the PRC government, explain the situation to them, and ask them to help avoid an embarrassing situation by providing assurances in writing, to the IETF, the hotel and the host, that the government does not support/encourage taking actions against the IETF in reaction to the actions of some individuals. If individuals break the laws and violate the customs of China, let them bear the full brunt of the law, but not the IETF. Obviously this is not an easy path to take because it takes a lot of patience and probably many failed attempts at contacting someone in authority who is willing to seriously dialogue with the IETF. You could try talking to the Beijing police, you could try asking the hotel and the host for their government contacts, and you could try working through various PRC embassies. But the bottom line is that if the IETF does agree to Beijing and the contract is signed and some incident takes place at the meeting, and the hotel or government shut down the entire IETF meeting as a result, it would be a great embarrassment to the People's Republic of China. Having said that, I've no doubt that the PRC government already has some idea who could prove to be an embarrassment and those people will not get their visas delivered in time to go to the meeting. But it is still worth having the dialogue with the PRC government. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Subscriptions to ietf-honest
I have lost my sense of humour about this. It's hard to see this as anything other than a systematic attempt to disrupt IETF activities. Forget about exotic laws like CAN-SPAM. This systematic attempt to disrupt IETF mailing lists should be enough to get a court injunction ordering him to cease and desist. The Internet is irrelevant. The technology is irrelevant. It would be interesting if IETF volunteers in Dean's jurisidiction were to attempt getting such an injunction on their own. Given that the activities disrupt the list for all members, perhaps a single individual could get an injunction that bars Dean from doing this at all. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
FSF is very well intentioned; don't understand me to say otherwise. That said, I think their view on IPR is pretty extreme - no IPR is acceptable. Perhaps that is their view as an organization, but if the IETF engages with the FSF to get individuals involved in the IPR discussions, I think you will find more flexibility of viewpoint. If the IETF chooses to ignore the FSF, I don't think that strategy will work. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposal to create IETF IPR Advisory Board
One suggestion, now a specific topic on this list if you care to respond directly, is for the creation of an IETF IPR Advisory Board to help people everywhere--including thousands of disaffected FSF campaigners--to understand why certain patents (including the Redphone patent) are not worth worrying about. - If there are thousands of disaffected FSF campaigners, this should be the FSF IPR Advisory Board. You have yet to explain why the aggrieved party is not willing to do the work to make themselves happy. There is the germ of a good idea here. History has shown that the FSF is very concerned with how the IETF standardisation process deals with patent issues. This is a reasonable concern given the FSF's raison d'etre. Therefore, why not proactively consult the FSF on any standards track document that makes use of patented material? Proactively drive the dialogue by getting the FSF involved at an early stage, and by providing a separate mailing list (ietf-comments) for discussing the IPR issues. Over time, the FSF folks will better understand how the IETF deals with IPR and will see that there is rarely the possibility of a serious problem. Some of the time, an issue won't be resolvable in a brief email discussion and in that case the IETF should ask the FSF to collect their thoughts and write an Internet draft that explains why the proposed plan of action is bad, and why the IETF should take some other plan of action. That draft can then go to the WG and get resolved before a new protocol ever reaches RFC status. If we do this, then there are unlikely to be flurries of activity during last-call. In addition, more dialogue with FSF members should prove to be useful in resolving some of the open questions about IPR, copyrights, licencing and so on. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Changes needed to Last Call boilerplate
(For Members of the IETF we can substitute People who are subscribed to the IETF Discussion list, if people think that is needed in place of the technically somewhat nebulous Members of the IETF.) If you really want to limit it to people subscribed to the list, forget the boilerplate, just configure Mailman differently. With the text above, don't be surprised when people learn that they can become bona fide IETF members by subscribing to the IETF discussion list and the new subscription volume swells exponentially. Given the contents of many of the letters received on the patent issue, I would expect the majority of those people to be willing, and capable of, subscribing to the IETF list in order to submit a comment. Also, don't be surprised when the next time this issue arises, the FSF encourages people to join the IETF WG discussing the next patent-encumbered draft. Fundamentally, the IETF is a legislative body crafting legislation that allows people to share intellectual property confident that they have the legal right to do so and that the risks from such sharing are minimized. Lobbying is fundamental to lawmaking. The roots of the IETF process are in the 1960's when people enhanced western democratic models with native American democratic models in which all voices are heard. Perhaps the solution to this type of issue is to solicit those voices earlier in the process, and then if there is no consensus, drop any further discussion of the draft. Patent issues affect more than just the select few who participate in IETF WGs and meetings. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
And there is in point of fact an entire police force tracking down scam artists using the postal mail. It is rare for blatantly illegal scams to come through postal mail since in order to get bulk mail rates, the sender has to be identifiable and accountable. The bulk of my unwanted postal mail is actually somewhat relevant since it is for products and services that are sold in England or my district of London. But I get lots of email for products in Russia, Canada, China, Korea and the USA which I could not possibly buy. Analogies can only take you so far. I think the real lessons from postal mail come from a fairly abstract level. For instance, requiring more effort to send the mail means that there is less frivolous mail. Accountability of the sender reduces the volume of illegal or abusive mail to a trickle. In the email world we would likely use very different mechanisms to require some per-message effort by senders or to make senders more accountable. No doubt any such mechanisms would be subvertable but again, the lesson is that if it requires EFFORT to subvert the mechanism, then it does reduce the magnitude of the problem and that in itself may be sufficient to solve the problem. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Fwd: The IESG Approved the Expansion of the AS Number Registry
But, with the expanded space, there is an issue of how to transition to the larger numbers. This is a software problem as much as anything. Indeed, there is a software issue here which does not seem to have been carefully considered. Until all software understands the bigger numbers, people will want to continue using the 16-bit ones. The IESG message talked about numbers from 65536 to some big number. Here suddenly, we see a reference to some number of bits. Meanwhile, to encourage the migration to 4-byte ASNs, the RIRs have Now there is a reference to some number of bytes. What is going on here? Is this a question of moving the maximum number from 65535 to something much larger or is it a matter of creating new notation to reflect the details of the BGP protocol change? Some people have been pushing to make the internal details of the BGP protocol externally visible even though the new ASNs are defined in such a way that any 32-bit numbers which happen to be equal to a 16-bit number are treated as if they were the old 16-bit number. In other words, if you were allocated 64999 as a 16-bit ASN, you have the right to use 64999 as a 32-bit ASN. Because of this, some people are demanding that a new notation be developed to place a punctuation character, either a dot or a colon, between the two 16-bit segments or between the 2nd and the 3rd byte, if you want to count bytes. Using this system, there can be no such thing as AS 65536 as was stated in the IESG message. Instead, that 32 bit quantity will be referred to as 1.0 or 1:0. On the NANOG list it has already been pointed out that a lot of network management software cannot handle such notation and in some cases, 1.0 could be interpreted as the IP address 1.0.0.0. It has been confirmed that one widely used PERL library interprets x.y as IP address x.0.0.y. Because of this I think it would be useful for the IETF to publish a draft defining the notation for AS numbers so that we can either keep it simple or, if a new notation is to be used, then publicly state the issues of software which needs to be changed. Such a draft should really come from the WG which extended the AS number in the first place. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Something better than DNS?
You can solve the problems in various ways (see Emin Gun Sirer's message) but most of them create a super-registry on the top of R1 and R2 and you are back to the unique registry model. This is a false statement. A basic course on distributed systems will cover lots of design alternatives where R1 and R2 are symmetric, mutually distrusting and there exists no super-registry, yet there is a way to establish whether R1 or R2 acquired the name first. This is the problem of using complex and sophisticated technical arguments against shared registy models. The fact is that the domain naming service delegates exclusive control over a subdomain to a single entity. From that model, companies like IBM are assured total and exclusive control of the subdomain ibm.com. If you change that model, then IBM ceases to have such exclusive control. I note that numerous organizations have taken an interesting subdomain and used it to delegate sub-subdomains to other parties. Such organizations can even share the sub-domain if they wish to. But doing that infects the entire sub-tree of their domain with the new model. In order to preserve the possibility that some domain owners can have total and exclusive ownership we need to maintain a single authoritative and exclusive owner of the root. Or in other words, if IBM wants to keep ibm.com then the root must remain under the control of a single exclusive authority. Fancy technology cannot change this. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Something better than DNS?
DNS is broken since people started disallowing AXFR transfers. Not sure I understand your point. You query a record, you get an answer. Why on earth would you want to suck all the world's zone files ? Some people want to publish their own Domain Naming Service with additional information such as new top level domains. But they don't wnat to go through any IANA/ICANN process. If they can suck down all the top level zone files then it is easy for them to publish an ALTERNATIVE DNS VIEW that contains their own additions. Anyone who uses their view will then see the so-called official DNS info as well as the overlay. In addition DNS is designed with a single one root scope. So if you have to deal with chinese, arab and russian namespaces then DNS probably is not the right choice :) Agree. Add to that the current architecture does not allow competition at the TLD level. There can only be one registry for any given TLD, leading to artificial scarcity and lack of consumer choice. This is yet again an attempt to extend the scope of the DNS beyond what it was designed to do. DNS was created because of the need for a distributed naming service and in today's Internet, the domain naming service is a critical part of the Internet's infrastructural underpinnings. It is not a product which is bought by consumers. It is, by design, controlled by a single authority at each level. If that were changed then companies like IBM would lose their authoritative ownership of ibm.com and that is not in their best interests nor is it in the best interests of consumers. The restrictions imposed by the current architecture provide the stability and reliability that is required in a system that plays such a critical infrastructure role in the public Internet. Aside from the technical requirements to return reliable answers to queries, it should also make it possible to have multiple registries for the same TLD The protocol does not prevent this. Indeed many private internets do operate their own root or add unofficial TLDs to their DNS. A good book on the DNS will explain how to do this safely. A lot of the people who want to see competition in the domain naming service, fail to understand the IETF's role in this space. The IETF can only specify a protocol. They cannot wave a magic wand and make the whole world start using a new protocol or migrate from an existing protocol. In fact, if there was significant demand for such competition, no support from the IETF would be needed. In 1991, http was created outside of the IETF. It met with such huge demand that a later version of the protocol was issued as an IETF protocol 5 years later in RFC 1945. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
database protocol. This also provides the opportunity for a new version of DNS, the domain naming service, that strips out all the unused cruft to enable domain naming service operators to simplify the software that they use. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: SRV records considered dubious (was: Re: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys)
p.s. rather than adding more and more burdens to DNS, what we really need to be doing is figuring out how to replace it with something more robust and more flexible. (Yes, you'd have to arrange that DNS queries and queries to the new database would return consistent results; you'd also have to make sure that DNSSEC didn't break, but those are both doable.) DNS is getting very long in the tooth, and is entirely too inflexible and too fragile. The very fact that we're having a discussion about whether it makes more sense to add a new RR type or use TXT records with DKIM is a clear indicator that something seriously is wrong with DNS. Adding a new RR type should not require a single line of DNS server or client library code to be recompiled, nor any changes to the configuration of any server not advertising such records. Hear, hear! The DNS features that are in operation and are required for a functioning domain naming service, are a subset of the DNS as defined way back in the days of that small research network with high hopes. Today's DNS is an absolutely vital and critical part of the world's telecommunication network. An architectural component in that role should be simple and robust. We need to create a new version of DNS that removes the cruft, matches what is actually used operationally, and is more robust, i.e. less reliant on distributed servers for its resilience. While I wish that the proponents of adding new RRs would notice that LDAP can do the same job without any need for registering a new schema with the IETF, I understand that people want to leverage a successful protocol. Therefore, I think that the IETF would be wise to define DDDBP (DNS Distributed Database Protocol) using the same basic DNS protocol but running on a different port number. Divert all the DNS enhancement work to DDDBP unless it clearly addresses a need for the domain naming service infrastructure. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
And since SMTP has been an utter and complete failure in operations, I find that to be a dubious point. Anything used by close to a billion people can't be classed a complete failure. The failure is not that it is ignored but that it is so difficult to operate. Both the end users and the server operators are unhappy with what they get from the email system based around SMTP, POP, SUBMIT and IMAP. It's like what Churchill said. It's the worst thing out there, except for all the others. There were no alternatives to SMTP on an IP network until Instant Messaging came along. IM is wildly successful even though it has the same problems as pre-SMTP email, i.e. there are multiple incompatible protocols and networks. It reminds me of the days people used to quote several email addresses, Internet, MCI Mail, UUCP, Bitnet, Compuserve. But even with these disadvantages, IM continues to gain mindshare because SMTP based email is so terrible. SMTP won in the market place because people want the ability to send and receive messages on a non-prearranged basis. This constraint tied to a complete inability to secure end points has led to your headaches. Furthermore, the problem is not limited to mail, but can be seen in IM, and may likely show up in other forms of communication. Much of this is simply the nature of software. It has nothing to do with software and everything to do with architecture. IM networks have less problems because all the participants share a relationship with the IM service providers. Nobody has yet tried to build an open-ended email network based on a chain of trust between participants. Instead we have the flat SMTP protocol open to all comers and two client protocols that do NOT support sending an email message. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The 'failure' of SMTP RE: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys
The DNS is a conspicuous success. Exactly my point. The domain naming system is a conspicuous success. Fiddling with the DNS is not going to make that success rub off on SMTP et al. The problem with the mail system has nothing to do with the protocol performance. The problems are caused by PEOPLE. SMTP, POP, IMAP and SUBMIT just don't fit the use cases that these PEOPLE require. That means that the problems with the protocols are caused by inadequate engineering. In particular the protocols do not anticipate what is necessary to deal with a population of a billion users. That is a problem but not an operational problem, the problem is architectural. Agreed. The problem is with the *EMAIL* architecture. In the beginning there was apparently only a very simple architectural idea that involved leveraging IP networks to transfer the files which were sitting in mail server spool directories. SMTP did that job well but, even with band-aids applied, does not suit the email architectural needs of the present day. a different directory scheme (Hello John) or network architecture (Hello David) won't help unless the new architecture takes account of the real issue - people. Agreed. A new email architecture must take into account the current use-cases which involve large numbers of people, multiple languages with no lingua-franca, primarily non-technical users, financially motivated criminal gangs attempting to leverage weaknesses in the architecture, and the knowledge that hierarchy tames complexity. Fortunately it is possible to retrofit infrastructure for dealing with people into the legacy systems which turn out to be rather better than the councils of despair would imply. I don't disagree that band-aids can make things better for a while. Or that huge efforts to create new band-aids are better than tossing the whole thing out. But I also believe that the band-aids are not a long term solution and that a series of band-aids is an extremely expensive way to reach a satisfactory email architecture. As far as I can see there is no good reason why the IETF shouldn't undertake work to define a new email architecture and then define the protocols required to create that new email architecture. The early SMTP system held together because there was ACCOUNTABILITY. There were few limits on what you could do but if you messed up there were consequences. Yes, there was accountability, but it was not in the email architecture and it was wholly unconnected to the email protocols and services. It turns out that a reliable email system needs accountability imbedded in it, not tacked on as an afterthought. Here is where the lessons of hierarchy taming complexity can be applied. Instead of a flat system where millions of hosts talk SMTP to random other hosts, we could have an architecture where hosts play a defined role in a hierarchy of roles. There would be protocols use for hosts to communicate with peers at the same level of the hierarchy and others for end-hosts to communicate up the hierarchy. And a CHAIN OF TRUST to bind them all together in a single cooperative architecture. Mail servers will still exchange messages with known and trusted peers. A new mail server operator will have to arrange a trusted peer relationship with one or more existing operators at some point in the hierarchy. A mail user will have a trusted relationship with a local server operator. Many messages will have to be relayed because there is no one-level trust relationship between sender and recipient. Mail will flow along the chain of trust. And everybody will be motivated to keep those chains intact because when they break, messages stop flowing. Knowing who sent an email with a high degree of confidence is the first step towards knowing whether they can be held accountable. Even knowing the last email hop with a high degree of confidence will allow accountability. In order to know this with a high degree of confidence, the organizations must have a relationship, probably contractual, and must be in contact. The fact that a chain-of-trust email architecture encourages organizations to maintain functional contacts is a very good thing from an operational point of view. On the contrary, I get calls from a new VC-backed startup touting exactly that type of scheme roughly every three months. VC-backed schemes cannot solve such a large problem which requires many organizations to participate in building a chain of trust. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [Ieprep] Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
But in the IP world, there is a full continuum of states in between. Some of these are candidates for a useful service, and some of which aren't. - Allowing a higher packet drop rate across all the lower priority calls. Note that this scenario gives so-called *IMPORTANT* traffic the priority that is *DESIRED* while still allowing other traffic to get through. In a disaster scenario like the New Orleans hurricane, the official command and control structure was not the sole organization doing useful work. In such a chaotic scenario, common in war and in disasters, it would be unwise to only have the option of shutting off everybody else's service by preemption. The low priority traffic could still be carrying mission critical messages that are crucial to dealing with the disaster scenario. This reminds me of an anecdote that a friend of mine recounted some years ago. During the a war in some African country, maybe Angola, the international phone lines were usually so noisy that it was impossible for the embassy to hold a conversation with their leaders back in Africa. Faxes were also virtually impossible to transmit. He solved this problem by installing a UUCP email system that communicated back to Africa using Telebit PEP modems. Unlike other modems of the day, the PEP protocol divided the potential bandwidth of the communications channel into 256 frequency ranges, tested each range and used as many ranges as were functional. This testing and choosing process was repeated periodically so that as the noise pattern shifted, PEP would search out the cleanest parts of the channel and use those. The bursts of data that succeeded in reaching their destination are analogous to packets and the channel seeking behaviour is analogous to routing/failover. The end result was a reliable email communications channel. It could and often did take many minutes to transmit just a few lines of text, but it did function and this allowed the embassy to function where before they were paralyzed. IP networks allow this same possibility, that of finding a low bandwidth end-to-end path amidst a cacophony of cross-traffic. The IETF should do some more education on how the existing protocol set could be used in disaster/war scenarios without needing any new features tacked on to it. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: WG Review: Recharter of Internet Emergency Preparedness (ieprep)
We need to resend in 30 seconds, perhaps, and if mumble time units elapse without successful delivery we need to initiate a response to the sender indicating that s/he should try another communication channel while we continue to retry this one. Waiting 30 seconds would be unwise in the scenario described. Instead of waiting, the sending application should be sending 2 or 3 copies of the message via different routes to ensure that it gets there as quickly as possible. For existing models on how to accomplish this in IP, you should look at the financial services industry where tickers and other market datafeeds must get to the recipient as fast as possible because millions of dollars are at stake. In this environment, datafeeds are sent via multicast. Each packet is duplicated and sent via two different multicast trees which travel over infrastructure which is entirel discontiguous, i.e. separacy is enforced right down to the physical layer. It works well and something like this is likely to be the right way to handle critical emergency communications. Note that an important aspect of this type of solution is that it defeats IP routing's concept of the single best path for a packet. This means that if you don't need the multiple recipients that a market data feed requires, you might find a way to do something similar with MPLS TE that is more suited to emergency comms. Those experts aren't in the ITU, and the ITU at this point doesn't have the expertise to even say what was said in my long paragraph above. And the ITU does not have applications layer experts which is what you need to design a communications solution for some very specific and very important applications layer requirements. Some people are assuming that lower level protocols need to be *fixed* to enable this but I do not agree that is the case. I do believe that having a requirements-generating working group is a good thing. Yes. And get some other applications domain experts to contribute such as people from the financial industry or SIAC. IMHO, the financial industry treats this matter with much greater care and importance than the defense and security sector because in the financial services industry, the impact of communications failures is immediate and can be severe. Unlike the defense and security sector who must deal with events sporadically, in financial services the events are numbered in transactions per second. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Improving Security with Encryption
I strongly agree and my entire laptop is encrypted. If this policy you suggest is taken only a little bit too zealously, your company will mandate encrypting your work files, If your company's goal is to prevent corporate espionage then this is a rather shortsighted way to do it. If an employee with such an encrypted laptop is sitting in front of the immigration police who ask him for the encryption passwords then he would be stupid to refuse to divulge it. A wiser move would be to require all confidential documents to be encrypted and stored on a server. Before travelling such documents should be deleted from the laptop. On reaching the destination, the documents should be retrieved from the server. This way, if a laptop is lost, stolen, or in the hands of some police agency in some country or other, there is no corporate confidential information on it. And if there is serious risk associated with the confidential information, whether monetary risk or legal risk associated with making information public, then this *TRAVEL* rule should apply to the daily commute as well. After all, some of you may have noticed this thing called the Internet which makes it easy to move around encrypted files to any part of the world where a laptop is likely to travel to. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
