Re: [83attendees] Usual recreational venue diatribe (was Ground transportation from/to CDG)
On 15 Mar 2012, at 11:47 , Shane Kerr wrote: Yet we know based on country attendance statistics that people attend meetings in their region much more than where they have to travel a great distance. So even if cost is not a huge factor, SOMETHING is. Not everyone goes to every meeting. Obviously for those of us who only go to some of them, it makes more sense to go to ones that are less costly/inconvenient. Maybe this is something that could be tried in a smaller scale first, for interim meetings or suchlike? If we're going to do experiments, I think there are better ones that we could do. One obvious one is video streaming rather than just audio streaming. Video that is good enough to read the slides would be very helpful. The next step would be for remote participants to send audio and preferably video back for asking questions and doing remote presentations. And we should also figure out that the purpose of the jabber rooms is / should be.
Re: [83attendees] Usual recreational venue diatribe (was Ground transportation from/to CDG)
[cc to ietf@ietf] On 14 Mar 2012, at 14:58 , Nathaniel Borenstein wrote: One idea I've toyed with idly for years is halfway in between: keep the physical meetings, but break them up into multiple locations. We could have physical meetings in Europe, North America, and Asia, with strong telecom links among them. We'd still have to all be on the same schedule, but the people making the time shift would at least be surrounded by others on the same odd schedule, and there'd be critical mass for services like meals in the middle of the night. Meanwhile, the travel costs and visa hassles would be reduced. That would combine the worst aspects of being at a meeting with the worst aspects of NOT being at a meeting. Also, regional travel is a lot cheaper than intercontinental travel, but when you add up all the other costs you really don't save that much. We still haven't figured out how to use jabber effectively during meetings (either the jabber channel replicates all the info that's also in the audio stream or it's pretty much idle), so PLEASE no experiments in this area. Let others figure this out and then we can adopt what works.
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On 27 Sep 2011, at 5:45 , Christian Huitema wrote: if an address space is somehow set aside, we have no mechanism to enforce that only ISP use it. So we have to assume it will be used by whoever feels like it. How is that different from the current situation? Is there a reason why potential users of 240/4 will refrain from that use because it's called class E but not if it's called ISP private? And who cares anyway? If people feel it's a good idea to use addresses in the 240/4 block, more power to them. That saves more usable addresses for other uses. It is also important to avoid mistakes during the transition period from IPv4 to IPv6. I understand that many actors are anxious and waiting for some kind of fix. This is a common scenario for making substantial mistakes... Agree. We have to make absolutely sure that all the hacks that are going to be implemented to stretch IPv4 don't find their way into the IPv6 world. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On 23 Sep 2011, at 7:21 , Benson Schliesser wrote: The STS may have similar semantics as RFC1918 space, in that it's non-routable on the Internet etc. But it is not meant to be used in the same scope. The draft isn't sufficiently clear on this to my liking. I think it should be explicitly stated that no services are to be hosted on addresses in this prefix. There is no support for the choice for a /10. Why not a /11 or a /9? There is no discussion on the consequences of filtering packets to/from these addresses, such as PMTUD black holes. Hosting the reverse DNS for these addresses within the prefix may or may not be useful. Did anyone try to talk to holders of legacy space that is not present in the global routing table, such as the US government, to see if their addresses can be reused for this purpose? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 240/4 unreservation (was RE: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC)
On 26 Sep 2011, at 18:41 , Keith Moore wrote: The problem isn't in the difficulty of finding these changes and fixing them, for currently maintained code. The problem is in the zillions of systems in the field that have assumptions about 240/4 wired into them, most of which either have no automatic upgrade mechanism, aren't set up to use it, or aren't being maintained. This is the traditional problem with using 240/4, but it doesn't really apply in this specific case, because those addresses will only be touched by the CGNs in the ISP network, the routers in the ISP network and the home gateways. So especially in the case where NAT444 is only used for new customers this may not be an issue at all. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 30 aug 2011, at 9:22, Henk Uijterwaal wrote: That is a 4.5 year difference in when the exact date is announced. This increase the risk that there is a clash with another meeting and people cannot plan much in advance. Come on, the idea that people need to know the date of a meeting more than 1.5 years out or they won't be able to plan their attendance is ridiculous. I don't even know which country I'll be living in 1.5 years from now. You also only look at the situation where the dates are completely open until after the venue negotiations are complete. I don't think we need to go that far, we could start by selecting two weeks long in advance and then choosing between those as the negotiations happen. This could be especially useful for a meeting in a region where more contraints than usual are expected. The question is what we, as a community, want: dates known early or flexibility to select the best venue at a late stage. I can only speak for myself, but $300/night is a big problem for me. I have no problem staying in non-official hotels, but obviously that only works when those are available and have more reasonable prices. Then again, I don't need to go to _every_ IETF meeting (I think I'm at 12 meetings in 9 years now) so I'm ok having a mix of cheaper and more expensive meetings. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 27 Aug 2011, at 17:43 , Marshall Eubanks wrote: I think that the meeting selection process is inherently iterative. Pseudo code might be something like - Find a list of all venues we can in the target area for the target week. The number of these is rarely if ever more than 10. So the most important objective is having the meeting during a week that was selected years in advance. I think we are now paying the price for that inflexibility. Obviously the date needs to be fixed at some point, but does it really have to be six years in advance? ( http://www.ietf.org/meeting/upcoming.html ) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: https
On 26 Aug 2011, at 16:24 , Tim Bray wrote: I'm increasingly coming to think that *everything* should be done with TLS unless you can prove it's harmful. Call me paranoid, but given the general state of the world, secure-by-default seems like the way to go. -Tim That would be nice in a world where such security didn't slow everything down, especially on high RTT links. HTTPS really makes everything a whole lot slower on a mobile device, not to mention using extra battery power. There is absolutely no reason mailinglist archives or most other stuff on www.ietf.org needs more protection than any other random web page and as such imposing the additional overhead on other people is very annoying. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: authenticated archives, was https
On 27 Aug 2011, at 19:42 , Joel jaeggli wrote: In the mean time, I would like TLS exterminated from the IETF website - any reason will do - since the cost to me far outweighs the benefit. So who decided to put it in, and on what grounds? Good question. For me it also causes more trouble than benefits. But let's split the difference and let the HTTP and HTTPS sites exist side by side for all pages that contain public information. The datatracker, wikis, working group chairs pages, registration, mailing list management and tools sites all support authentication, I would find it completely unacceptable to pass my credentials or activities I engaged in once authenticated in the clear. There's more to life than HTTPS. Such as digest authentication, which is probably sufficient for most of the above. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 29 Aug 2011, at 17:01 , Henk Uijterwaal wrote: If we want more flexibility in order to find better hotel deals, then we have to do something like: dates are fixed approximately 1.5 years out, and we do not mind having meetings back-to-back with other organizations on the clash list. That means that some folks will have to travel around the globe between Friday afternoon and Sunday morning in order to make it from one meeting to another. Is this so bad that $300/night room prices for hundreds of participants to avoid this issue is a good deal? One potential solution could be to select two or three weeks that don't clash or only minimally clash and then start the negotiations with a few more options, fixing the date a year or so out. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 29 Aug 2011, at 17:32 , Andrew Allen wrote: There likely are no such dates as there are telecommunications standards meetings of one kind or another virtually every week of the year (except Christmas and (western) new year). Then go from no clash to minimal clash. If it turns out that it's only possible to select one minimally clashing week in a target period then select that week. But randomness suggests that there will be times when there are multiple candidates that aren't too different. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Spurious MTU in IPv6 RAs Where WAN is PPPoE
On 9 jul 2011, at 15:51, Sabahattin Gucukoglu wrote: You're invited to file a report with http://bugreport.apple.com about this. Be sure to explain why fixing the broken path MTU discovery in the network is not an option and requiring the AirPort user to know enough about IPv6 router advertisement MTU options to set the value properly is an appropriate mitigation. This is bug #9739722, Airport: Configurable IPv6 RA link-MTU or MSS Clamping. Severity 2. THIS IS A BAD IDEA. MSS clamping is modifying packets exchanged between consenting hosts. As a rule the network doesn't get to do this. Unfortunately the situation with IPv4 is so bad that it's not realistically possible to avoid this when you have a path MTU smaller than 1500. But with IPv6 we have a new chance to punish the people creating the problem rather than the ones implementing PMTUD properly, so The Right Thing To Do is NOT fix any PMTUD breakage in properly behaving systems, but rather push people that configure their systems incorrectly to fix this. And it seems to be working, PMTUD black holes happen with IPv6, but they're relatively rare. Advertising MTUs smaller than 1500 when the uplink has an MTU smaller than 1500 is completely unnecessary because IPv6 has good path MTU discovery and doing this also limits the size of packets exchanged locally. Advertising an MTU of 1500 is also not proper behavior, BTW. However, I do think that it's a good idea for makers of home routers to allow users to set the MTU advertised in RAs to anything between 1280 and 1500 (inclusive, assuming ethernet), but this should not be done by default. I still plan to get http://tools.ietf.org/html/draft-van-beijnum-multi-mtu-03 published at some point and having widespread reduced MTUs advertising in RAs means one more hurdle to an internet with larger packets. This is something that's sorely needed: 100 gigabit ethernet transmits more than two average sized IP packets in the time 10 megabit ethernet sends one bit with the current average packet size of ~ 500 bytes. Despite the fact that virtually all hardware supports larger packets these days. But unfortunately our friends over at the IEEE aren't in the position to increase the ethernet maximum packet size because that would break backward compatibility (of course with every new standard they create new stuff that's going to break if they eventually do it, those NE2000 cards aren't an issue anymore today). So if anyone is going to do it it's going to be us here at the IETF because unlike ethernet, IP allows for some parameter exchange between hosts during neighbor discov ery (or ARP). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Spurious MTU in IPv6 RAs Where WAN is PPPoE
On 10 jul 2011, at 17:20, Masataka Ohta wrote: I was wondering what kind of unique perspective you would have here, and I wasn't disappointed: It means that rational operators MUST filter some ICMP and, not surprisingly, some operators will block all ICMP or all packet too big ICMPs That is more or less ok as long as they don't send any packets larger than 1280 bytes. If you want to send 1281-byte packets you MUST use PMTUD and thus you MUST accept incoming packet too big messages. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] I-D Action: draft-ietf-behave-ftp64-12.txt
On 8 jul 2011, at 16:37, internet-dra...@ietf.org wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF. Title : An FTP ALG for IPv6-to-IPv4 translation Author(s) : Iljitsch van Beijnum Filename: draft-ietf-behave-ftp64-12.txt Pages : 17 Date: 2011-07-08 I made a cosmetic change to the short title used in the page headers and, after this week's discussion with Rockson Li, added this sentence: The ALG SHOULD ignore the AUTH command and not go into transparent mode if the server response is in the 4xx or 5xx ranges. See the diff between -10 and -11 for more substantitative changes as a result of last call comments. So I believe we now have the final version of this draft. Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reading drafts on an ipad
On 6 jul 2011, at 17:38, Cullen Jennings wrote: Has anyone found a particularly good solution to reading drafts on an ipad? I saw xml2rfc now has the option to convert to epub, which would make it easy to read drafts on the iPad and other mobile devices, but unfortunately when I tried to convert a draft it didn't work. But then we'd still need the XML or epub versions of drafts to be made available to all. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [BEHAVE] FW: Last Call: draft-ietf-behave-ftp64-10.txt (An FTP ALG for IPv6-to-IPv4 translation) to Proposed Standard
[Please note that this message is going to many mailing lists, please trim as appropriate when responding.] I submitted a new version of the draft which addresses most, if not all comments. The most notable change, which I would like to ask previous reviewers to look at again, is the handling of the AUTH command, which is now made much less prominent as a way to make the ALG transparent (clients should use ALGS for this) so text specifying interaction of multiple ALGs could be removed. The draft: http://tools.ietf.org/html/draft-ietf-behave-ftp64-11 The diff with -10: http://tools.ietf.org/rfcdiff?difftype=--hwdiffurl2=draft-ietf-behave-ftp64-11.txt Thanks everyone for reviewing. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: tsv-dir review of draft-ietf-behave-ftp64-10
Thanks everyone for the comments. I'll look into the other technical comments later this week, but there's one I can respond to right now: On 4 jun 2011, at 0:16, Fernando Gont wrote: * Section 1, page 3: In 5 cases, issuing the EPSV command to the server led to a significant delay, in 3 cases followed by a control channel reset. Could you please clarify what was the cause of the delay? These tests were towards FTP servers found around the internet, so we were unable to determine what exactly those servers were doing, other than what we observed remotely. We speculate that this is the result of a firewall placed in front of the FTP server that monitors the control channel and opens ports based on the PASV or PORT commands, but the firewall doesn't support EPSV so no port is opened and the data channel can never be established. I can put this discussion in the draft. (I seem to remember it was in an earlier version.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Adventures in IPv6
On 12 apr 2011, at 1:39, Doug Barton wrote: http://bens.me.uk/2011/adventures-in-ipv6 What a bunch of whining. When I first started doing IPv4 it was much harder than this. Of course, I think the conclusion is basically wrong, *not* doing IPv6 is much worse than breaking the finger-pointing circle, and making it work by whatever means necessary. Much worse for who? Just because we (may) believe that IPv6 is the way forward doesn't mean that the providers or consumers of Internet services will agree with us. I'm sure most airline passengers have few opinions on the merits of wingtips, either. The engineers can tell you they are a good thing. We don't let the public's ignorance override that judgement. The consumers just want to watch their videos and read their mail. The providers just want to sell them that capability. IPv6 needs to solve more problems than it creates, or else it's not the right answer. It's too late for that discussion now. If there is some aspect to IPv6 that is broken, we need to fix it as soon as possible. But IPv6 is been around for 15 years with ONE WEEK to go before APNIC runs dry of addresses it can give out through the regular process, so debating the merits of design choices now is pointless. If you read that whiney blogpost you'll see that none of it is about problems that the IETF can fix. It's also important that we show a little understanding and compassion when people whine (unlike what I've been doing here) but only a little, mostly we have to convey that IPv6 is ready for prime time and no negotiation is possible at this point. It's strange, but people actually get angrier when you agree with them when they complain. They want and expect you to hold your ground while they vent and afterwards they are usually ready to face reality. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Call for a Jasmine Revolution in the IETF: Privacy, Integrity, Obscurity
On 5 mrt 2011, at 5:06, Dean Willis wrote: 1) Privacy and Integrity: We believe that intermediaries should be neither able to understand nor alter the transmitted material without the explicit consent and awareness of the users. 2) Privacy and Obscurity: We believe that observation of a traffic flow pr sequence of traffic flows should reveal as little information about the application or user of the application as possible Privacy and obscurity are tools that cut both ways. It can protect legitimate communications from evil regimes, but it can also shield illegal behavior from the law, or privacy violations commited by applications, or services running in a browser from the user. It also makes debugging orders of magnitude harder, uses more overhead and engergy and slows down the communication. (Especially in mobile networks where one end is on battery power and the extra round trips required to negotiate encryption and authentication are typically slow.) As such, it would be a very big mistake to start encrypting ALL communication. Whether the applying these mechanisms is sufficiently beneficial to be worth the numerous downsides should be evaluated on a case-by-case basis. It's not the IETF's job to force vendors and users to do something that they would otherwise choose not to do. You're trying to attack the problem from the wrong side, anyway: you assume using the large infrastractures that are easy to control by states and then try to add a layer of protection. It would be better to work around these infrastructures completely. Why is it that when I email my colleague two meters away, within easy wireless range, that the message goes through the servers of Google somewhere (not even sure in which country those are)? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Use of unassigned in IANA registries
On 14 jan 2011, at 23:06, Martin Rex wrote: Frankly, I'm actually more concerned about code assignments for severely IPR-impaired algorithms (e.g. Elliptic Curve related) than about GOST. (Admittedly, the GOST 34.10-2001 signature algorithm appears to use Elliptic curve math, and it's entirely unclear to me whether and how existing EC-related IPR claims might apply.) Withholding registration just means that people are going to pick an unregistered number with all the problems that that entails. In cases where there are no scarcity issues registration should happen as long as there is a reasonable expectation of non-negligible use, regardless of whether the registered protocol is endorsed by the IETF (whatever that means) or IANA. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Optimizing for what? Was Re: IETF Attendance by continent
On 8 sep 2010, at 3:13, Marshall Eubanks wrote: or people who only attend meetings in their home region, Am I imagining things or are more and more American attendees foregoing meetings outside North America? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: The Evils of Informational RFC's
On 8 sep 2010, at 17:03, Eric Burger wrote: in today's environment of thousands of Internet-connected publication venues, why would we possibly ask ourselves to shoot ourselves in the foot by continuing the practice of Informational RFC publication? Link rot. On Sep 3, 2010, at 7:48 PM, Richard Bennett wrote: It is bad form to repeat the entire previous speaker's message, especially AFTER you've made your point and this text is now certainly no longer needed to support that point. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT behavior for IP ID field
On 2 sep 2010, at 10:04, t.petch wrote: So it is legal to rewrite the DF bit from 1 to 0. I also know that this happens in the wild because I used to do this at one time. Curious; RFC2402 says Flags -- This field is excluded since an intermediate router might set the DF bit, even if the source did not select it. which is a licence to set the bit but I had not thought to reset the bit. RFC791, RFC1122 and RFC1812 would appear to be silent on this. Ah, I did't read that far. Not sure why a router would set the DF bit, though, that creates a PMTUD black hole. I agree that there is no explicit permission to modify the DF bit in transit, but RFC 2402 certainly recognizes that this may happen in practice. It's a pretty effective way of getting rid of PMTUD black holes that you run into when there is an MTU smaller than 1500 in the middle of the network. Most people just rewrite the MSS option in TCP SYNs (which are certainly NOT defined as mutable in transit), though. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
On 2 sep 2010, at 7:40, Christer Holmberg wrote: In my opinion, the discussion whether we should change the meeting calendar (not having meetings during summer vacation months etc) was much more interesting and useful. To revisit that: if we move up all the meetings by one month, we gain a number of advantages: - We avoid the middle of the vacation season, especially in Europe. This is an advantage if we want to meet in places that also attract tourists, although it could also be a disadvantage under some circumstances. Transport and other services aren't in vacation mode. - We can go further south for the summer meeting without overheating - We can go further north for the autumn meeting without undercooling A february meeting would be in the coldest part of winter, so that meeting would have to be in a place where winters aren't too harsh. But then, march in Minneapolis is no picnic either. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: NAT behavior for IP ID field
On 31 aug 2010, at 22:04, John Kristoff wrote: I'm trying to locate an RFC that spells out the behavioral requirements, expectations or guidelines for NAT handling of the IP ID field, particularly for UDP messages. If this is not written down anywhere, do NATs generally rewrite the ID field with or without the MF bit set? I don't know. We had a discussion about this in the BEHAVE working group while working on stateful IPv6-to-IPv4 translation. Unless I missed something, the ID field needs uniqueness for any combination of source, destination IP addresses and protocol. Assuming the source address doesn't change, this means an ID counter should be maintained per destination address + protocol pair, so the maximum number of packets can be transmitted for each such pair before an ID value is reused. This would be the optimal host behavior, and NATs should act like hosts in this regard. Reusing the ID field from the original packet has a much higher chance of seeing the same ID field for outstanding fragments of a different flow, which can cause undetected data corruption in 1 in 65535 cases when the TCP/UDP checksum doesn't catch this. Note that DF=1 doesn't save you from all of this, as RFC 2402 says: Mutable (zeroed prior to ICV calculation) Type of Service (TOS) Flags So it is legal to rewrite the DF bit from 1 to 0. I also know that this happens in the wild because I used to do this at one time. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Attendance by continent
On 31 aug 2010, at 1:13, Tobias Gondrom wrote: My vote is strongly in favor of 1:1:1. 1. First, the location _is_ a significant barrier to entry for newcomers and other contributors. Optimizing only for the current status quo does create a strong perpetual cycle of self reinforcing structure of contributors from the favored location(s). You assume that having a meeting on your home continent magically makes attending a meeting much easier. I don't think that's necessarily the case. Just consider the language issue. I think we can safely assume that everyone who thinks about attending IETF meetings speaks English. So attending a meeting in a country where English is the official language is much easier than in a place where few people speak it. Even in the Netherlands, where virtually everyone speaks at least some English, there was a bit of a language barrier because signs, menus, etc where often only available in Dutch. Also, flying across a big continent can take just as long as flying across an ocean. And although there is a correlation between travel distance and cost, that correlation is well below 1. Sometimes intercontinental flights are the same price or cheaper than regional flights, and often the difference is small enough that it disappears in the noise of hotel prices, ground transportation costs, food expenses and the like. Last but not least, attendance is only one metric. If it were the only relevant one, we'd have to meet on a Cisco campus once every three years, as about 10% of the attendees are employed by Cisco. Even though Asian attendance has been on the rise, contributions from Asian IETFers seem to be lagging their attendance numbers. (For instance, as far as I can tell from the names, none of the IESG members is from Asia.) For all these reasons, I think that 1:1:1 is not warrented at this time. Maybe it will be in a few more years, but I think we should first see how well meetings in places like Beijing go before committing to having a meeting in Asia every year. Meeting in Europe seems to lead to compromises. Maybe Asia will turn out to be better in this regard, maybe worse. I don't think we want to have meetings with more compromises just to appear balanced. Consider that contributors usually start as newcomers, attend several meetings, then write a draft, I don't know about you, but I wrote drafts before my first meeting. join more WGs and maybe chair a WG. But if you make it hard for newcomers to attend several meetings they are at a severe disadvantage to become future contributors. If that were true we'd need to go to places where we _don't_ have attendees yet, not to Asia which has been sending a steady supply in recent years. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Meeting Venue Preference Survey
On 28 aug 2010, at 3:04, James M. Polk wrote: I'm going to pile on what Michael and Mary have already said, by saying the comparable list of cities (Minneapolis, Orlando, Vancouver, Barcelona, Prague) isn't even remotely close to including Maastricht. Each of the above cities are accessible internationally via air (as in: on intercontinental flights), and from many cities. Maastricht has a very small airport that I'm not sure you can get to it outside of NL and Germany (I'm sure I'm wrong, but I'm not wrong by much). You certainly can't get to Maastricht from North America or Asian directly. I've been critical about this beforehand, but let me defend Maastricht a little here. You guys are applying American thinking here. Don't think of Maastricht as a town with an unusably small airport, but rather think of it as having a nice big airport (that would be schiphol, often called amsterdam airport) that happens to be unusually far away from the city. If you fly into New York ground transportation is going to take a good while, too. From schiphol to Maastricht is worse, but only by a factor two or so. Actually much of the confusion regarding travel was because there was more choice than usual: people were flying into three airports (AMS, FRA, BRU). From Frankfurt and Brussels the train travel was international, and as some people have experienced, the combination of international flying and international train travel is less than ideal. But apparently people preferred this to flying through schiphol. That's their choice. I'm pretty sure that as someone who doesn't drive going to the Anaheim meeting would have been more problematic for me than Maastricht. Although I'm from the Netherlands I had never really visited Maastricht before, and I must say it's a very nice city. I'm looking forward to going back for a repeat visit. The main thing I ended up disliking about this meeting venue was the location of the conference center in the middle of nowhere. Having to travel for at least 15 minutes just to buy a soda or a sandwich (outside lunch hours) was REALLY annoying. All in all Maastricht is getting a passing grade from me, but I certainly hope that we can do a bit better in the future. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Meeting Venue Preference Survey
On 30 aug 2010, at 19:57, Randall Gellens wrote: 8. Would you attend if we held the IETF in Africa? 9. Would you attend if we held the IETF in South or Central America? Like the question on an earlier survey about Quebec City, I think it requires more information and more individual research to have a good answer. Which venue in which city? How hard is it to get to the city and venue? Basically the only thing the survey gives us is how many people would never go to a meeting on those continents regardless of the particular circumstances. There wasn't even a why not. A few months ago the IEEE had its ICC conference in Cape Town. I believe around 800 people attended. For me this was about 13 hours of flying (MAD-AMS-CPT), although there was no timezone change. For someone from North America that would probably be a lot longer. My flight was affordable, but only available during weekends so I was forced to stay a few extra days. I would say that the security situation in Cape Town was barely acceptable, the mobile phone infrastructure wasn't acceptable at all (almost impossible to make international calls over the mobile network, including calls to colleagues also in Cape Town) and internet access was also a huge problem but presumably the IETF or host would take care of that if we were to meet in such a place. If things are so problematic in the safer of the two biggest cities of the richest country of the continent I can't imagine the IETF having a succesful meeting elsewhere on the continent. Of course I can't know for sure after only vi siting one city in Africa once. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: All these discussions about meeting venues
On 30 aug 2010, at 20:25, Randall Gellens wrote: In both directions between BRU and Maastricht I had to change trains multiple times, and several of the stations required me to carry my luggage up and down non-trivial staircases. I wondered at the time how someone in a wheelchair or who had mobility difficulties could manage. I realize these stations were in Belgium, not the Netherlands, so perhaps this explains it. In the Netherlands more modern stations have elevators. Intercity trains have an elevated entrance, so wheel chair users must inform the Dutch Railways of their travel plans so a ramp can be positioned for ingress and egress. The journey from schiphol airport to the Maastricht main station required at least one change, but that one could be done as a cross/same platform change. I haven't heard of any wheel chair accessible planes, though. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Optimizing for what? Was Re: IETF Attendance by continent
On 30 aug 2010, at 21:57, Olaf Kolkman wrote: If you want to be fair to the individual participants you have to optimize in such a way that attending 6 meetings costs the same for every individual that regularly attends the IETF. Obviously one can only approximate that by putting fairly large error bars on the costs but isn't the X-Y-Z distribution where X= approx Y= approx Z the closest optimum? (or finding one place that sucks equally for everybody) Am I missing something? Yes. Optimizing for min(X+Y+Z) WITH the constraint X=Y=Z is almost certainly going to produce a higher X+Y+Z than without that constraint. In other words, if you want to be fair the total expense for the entire community will be larger. Contrary to popular belief, distance is not the most important factor in travel expenses. My flight from Madrid to Dublin cost almost what I paid to fly from Amsterdam to Minneapolis a few years before. Hotel rates have a much bigger impact, especially now that the official IETF hotels seem to be getting more expensive every time we meet. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Optimizing for what? Was Re: IETF Attendance by continent
On 30 aug 2010, at 23:47, Hadriel Kaplan wrote: Therefore, I propose we meet in Hawaii (and Kauai in particular) from now on. We can even rotate islands if people get bored. No, we'd still have to rotate oceans. Iceland is nice and close to both NA and EU (farther north generally helps), but we still need something in the Indian Ocean. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
tools location
Why? inline: Screen shot 2010-07-25 at 14.14.45.png___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: tools location
On 25 jul 2010, at 14:34, Thomson, Martin wrote: This is the venue map page: http://tools.ietf.org/rooms ? The reason is so that it can display where you are on the map. Right. I had opened this page in a background tab so I didn't make the connection. Safari on the Mac doesn't seem to be able to find its location at all, though. And as there's no GPS reception indoors (certainly not without any windows) I doubt _any_ system could provide a location that is accurate enough to be usable here. p.s. UI design doesn't seem to be a strong point here - modal notifications are an annoyance. Firefox 4.0 gets it almost right, but the dialog appearance and usability suck. A popup is ok if it's a reaction to a user action, not so much immediately upon loading the page. As long as we're providing constructive criticism: on the little program booklet the maps are tiny but still mostly readable, but on the web page the text is too small to be deciphered. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: tools location
On 25 jul 2010, at 15:29, Scott Brim wrote: Are we resurrecting that marvelous app that shows where you are based on wifi? Yes. The Google streetview + wifi snooping truck should make its round through the MECC shortly, please don't stand in its way. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On 21 jul 2010, at 5:27, Mark Andrews wrote: The only keys that have to be widely distributed are those for the root zone and that's a similar problem to distributing the list of root nameservers and their addresses. Millions of recursives server operators have managed that. Would be great if the list of root servers and list of trusted root certificates could be distributed in one easy to install file... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
On 30 jun 2010, at 23:55, IETF Chair wrote: To gain access to the IETF network, you will need to provide a credential. Your primary credential will be your registration ID. You can find your registration ID on the registration web page, in the response email confirmation you received from the Secretariat, on your payment receipt, and on the back of your IETF meeting badge. Your Registration ID will be your user name, and it will be used with a password that will be provided at a later date. This same password will be used by all attendees. When and how will this password be distributed? I'll be arriving on saturday (to attend a workshop at the venue), it would be helpful if those who arrive early don't have to wait to get on the network until registration opens sunday at 11. (It occurs to me that a good way to give out this information pre-meeting is through inclusion on the payment receipt.) Also see Mark Andrews' message, on some systems it's useful or necessary to know the exact authtentication type that will be used. Thanks, Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On 16 jul 2010, at 14:23, Russ Housley wrote: I am passing on this announcement, and I want to add my thanks to everyone in the Internet community that played a role in deploying DNSSEC. Too bad it doesn't work for me. Here IANA publishes info that needs conversion steps that I don't have tools for to perform: http://data.iana.org/root-anchors/ And pulling down the key from the root servers doesn't give me something that works. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On 16 jul 2010, at 18:40, Andrew Sullivan wrote: Define works? Less of this: validating @0x82e9000: . DNSKEY: please check the 'trusted-keys' for '.' in named.conf. If anyone can point me to a key I can paste in my BIND config that will allow me to actually validate domains that would be great. And/or perhaps the right information hasn't propagated through the DNS system? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On 16 jul 2010, at 19:56, Ronald van der Pol wrote: http://fanf.livejournal.com/107310.html Thanks! That was very useful. I finally got it working. Yes, me too. I would also like to check the output for a zone that is verifyable not correct. Any examples of signed RRs with an incorrect signature? I skipped this step: In the options section of named.conf you should have the directive dnssec-lookaside auto; This enables DNSSEC lookaside validation, which is necessary to bridge gaps (such as ac.uk) in the chain of trust between the root and lower-level signed zones with the result that www.ietf.org, www.iab.org, www.isc.org, all fail to validate. Not sure what the deal is there. Only www.nic.cat works. BTW, this is great: https://addons.mozilla.org/en-US/firefox/addon/64247/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
I should know better than dive back into this discussion... On 13 jul 2010, at 18:05, Phillip Hallam-Baker wrote: Con: There is no cost to generating the cert, the cert can be generated after the device ships. Thus there is no degree of accountability established in the presentation of a cert. If a user abuses the network (e.g. to send spam) there is no bar to prevent them ditching the banned cert and re-applying for another. The cost of generating the cert can be more than just generating the cert. For instance, it could be made necessary to have the cert signed by someone who is presumably trustworthy. Or they need to build up some reputation. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
On 13 jul 2010, at 7:19, Hasnaa Moustafa wrote: I understood that the train runs daily from Brussels to Maastricht. There are more than 10 connections daily. I can't seem to find the direct Brussels - Maastricht train right now, though, the best options I see are with two changes. When in doubt, consult www.bahn.de On 13 jul 2010, at 7:49, Ole Jacobsen wrote: These are the trains I am taking: Sunday, July 25: ICE 138 Frankfurt Flughafen Frnb - Eindhoven 0943-1247 IC 841 Eindhoven - Maastricht 1302-1404 One change, easy enough. Note though that there are options with more changes that are more than an hour faster, Eindhoven is about 100 km beyond Maastricht seen from Frankfurt. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
On 13 jul 2010, at 9:22, Ole Jacobsen wrote: Right, but Dutch trains are not nearly as nice as German ICE trains. There are many different kinds of trains in the Netherlands. Indeed only some of them equal ICEs. However, by traveling through Eindhoven you're almost certainly subjecting yourself to more than an hour in a VIRM: http://en.wikipedia.org/wiki/NS_VIRM With FRA - Cologne - Liège - Maastricht you're in an ICE and a thalys, which should be pretty good, but also half an hour in a Belgian let's call it classic train. But you get to avoid Dutch trains altogether and you save 1h20 at the expense of an extra change. You can also do FRA - Aachen - Heerlen - Maastricht but the last leg has the unusual 2+3 seating arrangement in 2nd class, so you may want to upgrade to 1st class where you also get to enjoy a 230 V outlet for your laptop and save another 6 minutes. (The newest VIRM trains, which may or may not be used on the Utrecht - Eindhoven - Maastricht route, also have power in first class.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
On 13 jul 2010, at 11:38, Jaap Akkerhuis wrote: That's the same software. If b-rail.be is competent about updating its route database with other companies' trains, then the results will be exactly as good as for bahn.de. In that case, give ns.nl (dutch railways) a try. They seem to list during the day a direct train between Maastricht/Brussels nearly every hour during the day. During work days, yes, not the weekend. This is strange, on bahn.de the direct connections from Brussels to Maastricht fail to show up for most of the day on the 23rd. (You still need to change at Brussels north, central or south coming from the airport, though.) Ole: the Aachen/Liège route is 2 changes with 3h07 travel time while through Eindhoven is 1 change at 4h30. Change-wise I'd say it's a wash because the Eindhoven - Maastricht train is a double decker which means you're probably going to have to haul your luggage up and down some stairs. But Eindhoven is a nice city, you could do worse than spending some time there. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: web security happenings
On 13 jul 2010, at 18:49, Peter Saint-Andre wrote: fun technologies like AJAX but also opens up the possibility for new attacks (cross-site scripting, cross-site request forgery, malvertising, clickjacking, and all the rest). Isn't this W3C stuff? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
On 12 jul 2010, at 17:47, Andrew G. Malis wrote: Do you know if there is any sort of shuttle van service from Brussels Airport to Maastricht? That could be an easier option, given the luggage. As my company will be paying, I don't mind a higher cost as long as it's not astronomical, as I suspect a taxi or limo would be. I don't know of any service like that. Don't forget Maastricht is an hour and a half away from Brussels. Maybe the organizers know more. There is a train that only requires one change but it only runs on weekdays. Also, you still need to get from the train station to your hotel. That said, I never found traveling with luggage by train _that_ bad. Good luck, Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
Sorry about my previous message, this was a private message that I accidentally sent to the list. The one I really had in mind: On 12 jul 2010, at 19:53, Chris Elliott wrote: I thought we were talking about how to do this for the meeting in Maastricht and then in Beijing. I agree that manufacturers could make this easier for all of us. I have no idea where or why this discussion went off the rails (must be the heat, note that Maastricht is in the part of the Netherlands that gets the warmest in summer) but: WPA works just fine on anything that rolled out of the factory in the last half decade. It's also not particularly hard to use: select network, type user name, type password, click connect or words to the same effect. There is no step 5. I would even argue that restricting everything to WPA2 and 802.11g or better would be entirely reasonable by now. BTW: do we get 802.1x on the wired ports in the terminal room? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On 6 jul 2010, at 23:45, joel jaeggli wrote: What I'm missing is what happens with the information described under Registering to attend a meeting or social event:, there are no retention periods mentioned (that I noticed). the trust's records retention policy already deals with registration. So? If you're going to have a privacy policy it should have this in it. Currently, there's not even a pointer. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On 7 jul 2010, at 14:02, Alissa Cooper wrote: Data retention is addressed explicitly in section 5: What's missing? What I said: the stuff that gets asked for during registration and payment. Apparently I didn't notice the link to the IETF trust. However, I don't see the point of having a document like this if it only provides a subset of all information, there shouldn't be a separate privacy policy for the trust. Or perhaps it's better to just forego this effort, as spends a lot of text kicking in open doors. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On 7 jul 2010, at 16:32, John Morris wrote: And, if you indeed think that something is missing, perhaps you could suggest some language to address your concern, rather than just dismiss the entire effort. I think it's completely legitimate to question whether efforts like this are worth the resources they soak up. The first time I went to an IETF meeting I was shocked by the amount of talk about the internals of the IETF itself that went on. We should really try to minimize this navel gazing and only indulge in it when clearly needed, something that hasn't been shown to be the case here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On 7 jul 2010, at 17:23, John Morris wrote: Well, as someone who believes that *all* websites and online-operating organizations should have a clear and accessible privacy policy, I think it is beyond embarrassing that the IETF does not have one. The IETF got along without one for two decades just fine. In the meantime, BGP and HTTP, to name just two of the protocols without which the internet and the web wouldn't exist, still don't have standard status. What do we want to spend our time on? Create more text that people will end up reading that doesn't add anything to their life or the good of the internet, or make some progress on our chartered work? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF privacy policy - update
On 5 jul 2010, at 18:05, Alissa Cooper wrote: 1) Respond on this list if you support the idea of the IETF having a privacy policy (a simple +1 will do). I'm torn between good to have this written down and do we really need to go out and look for more process work. 2) If you have comments and suggestions about the policy itself, send them to this list. What I'm missing is what happens with the information described under Registering to attend a meeting or social event:, there are no retention periods mentioned (that I noticed). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
On 2 jul 2010, at 2:30, Phillip Hallam-Baker wrote: It has taken ten years for WiFi to get to a state where an adequate credential mechanism is supported, and it is still clunky. What are you talking about?? Enterprise type WPA where you authenticate against a back end server has been around for years, and with WPA2 it supports good encryption, too. And they still don't have a decent mechanism to support the typical coffee shop type access mode. Well, you could use WPA(2) there too. People who don't have a working account yet for the hotspot in question would then log in as guest, create an account and then log in with that account. But I would argue that the IETF in general has ignored access control to IP networks and how this interacts with provisioning of addresses and other information once PPP was out the door. Look at the backflips that are required to provide ethernet-based broadband access. Although we can partially blame this on the lack of uptake of 802.1x which handles the authentication, but that still makes (IP-over-)ethernet-based broadband problematic because of its point-to-multipoint model that isn't appropriate for providing services. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Admission Control to the IETF 78 and IETF 79 Networks
On 1 jul 2010, at 19:07, Andrew Sullivan wrote: This is useful, but not quite what I was asking. Clearly, the above means that the logs exist during the meeting, while we are at the host venue. I think it is safe to say that under some legal regimes, a government could require the delivery of such existing logs to them. I would very much appreciate assurances that such logging will not occur, and that there will be no live feed of such information to third parties, such as government or law enforcement. A week's worth of correlation between my MAC address and the IP addresses that I exchange encrypted information with is not something I think any government needs to have. Of course if a government has cause to believe that a given user is misbehaving they still have the option to talk to the NOC staff and have them obtain information about this user. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF 78: getting to/from/around Maastricht
Some more Amsterdam airport - Maastricht train info: On 27 jun 2010, at 22:01, Iljitsch van Beijnum wrote: From there, there's a train to the city of Utrecht every 30 minutes at x.29 and x.59. This is a 33 minute ride. When you arrive in Utrecht, change to the train to Maastricht, which should arrive at the other side of the platform within minutes. This train ride takes 125 minutes, for a total travel time of 2.44 hours. Note that there is usually no snack or beverage service in trains and the change in Utrecht is only five minutes, so stock up before leaving schiphol. Or take a break somewhere along the route, there's a train every 30 minutes. Eindhoven is a nice big station halfway between Utrecht and Maastricht with at least two coffee places. It turns out that the train to Maastricht is sometimes split in two in Sittard, and the other half goes to Heerlen. When you get into this train, it will show where the front part (voor or voorste deel) and where the back part (achter or achterste deel) go. So go sit in the right part. In Sittard, there will be an announcement telling you in which part you are, ask a fellow traveler if you don't understand the announcement. (The announcement may be repeated in English, German and/or French, but it may not.) You can also ask the conductor beforehand, although conductors aren't always seen. If you end up in Heerlen, just take the train from there to Maastricht, this takes about half an hour. About the coffee break: there is also another train that leaves schiphol at x.14 and x.44. This one stops in Utrecht, Den Bosch / 's-Hertogenbosch and Eindhoven (and a few times a day it continues all the way to Maastricht). If you take this one, you can change trains more or less in the middle of your journey in Den Bosch or Eindhoven, and you'll have 18 minutes to find the other platform and get some coffee, a soda and/or a snack at a Kiosk. Pronunciation: ch in schiphol, Utrecht and Maastricht (and the g in any word except as part of ng) is like in Loch Ness or German ich. (In most of the Netherlands it's pronounced more glutterally, but not in Maastricht where they have soft g.) aa in Maastricht is like hh when someone kicks you in the shin. hee in Heerlen is like in hit (but ee is usually like in hey). U in Utrecht is like ü in German für. Ei in Eindhoven (same thing for ij) is something in between ey and aye. oo is always like the o in hope, never like oo in foot. d at the end of a word is pronounced as t. n in words ending in -en is often not pronounced, so the -en becomes a schwa. In general, vowels are pronounced like in other continental European languages, except u (see above), double vowels (and ie in the case of i) are just longer versions of the single vowel and consonants are pretty much like English except g (see above) and th is just t, there's no sound like the English th. There's also no sound like the English g. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF 78: getting to/from/around Maastricht
This is some information about trains to and from Maastricht and the busses within the city. Probably more than you ever wanted to know. If you use an airport other than schiphol (Amsterdam), then see my earlier message about advance travel info. Schiphol has a big train station right underneath the arrivals hall. From there, there's a train to the city of Utrecht every 30 minutes at x.29 and x.59. This is a 33 minute ride. When you arrive in Utrecht, change to the train to Maastricht, which should arrive at the other side of the platform within minutes. This train ride takes 125 minutes, for a total travel time of 2.44 hours. Note that there is usually no snack or beverage service in trains and the change in Utrecht is only five minutes, so stock up before leaving schiphol. Or take a break somewhere along the route, there's a train every 30 minutes. Eindhoven is a nice big station halfway between Utrecht and Maastricht with at least two coffee places. There is also a small second train station in Maastricht that is within walking distance from the MECC venue. This one is called Maastricht Randwyck and you need to change trains at the main Maastricht train station to get there. But it's probably easier to get a bus or taxi. If there are issues with the train to Utrecht, go through Rotterdam instead, NOT Amsterdam. Note that for some trains to Rotterdam you need a special ticket. In the main station hall there are boards that indicate when trains for different directions leave and from which platform. Double check the indicators above the platforms but don't pay too much attention to what it says on the train itself. Note that at the schiphol train station the departure platform is only decided minutes in advance, but it's between two sides of the same platform so this is not a big deal. There is no smoking in the trains and on the platforms only in proximity of the ashtray poles. The main train stations have KPN wifi hotspots: https://portal.hotspotsvankpn.com/templates/dispatcher.asp?page_id=home_inet_uk They roam with Boingo, Trustive, WeRoam and iPass. A few trains have wifi now, which should be free. I don't know how this works, there is no information available. If a train has a screen that shows dynamic travel information it's probably wifi-enabled. About train tickets: in theory, you can buy one online. In practice, you can't and there is no point anyway as you don't save any money. You can get a regular paper ticket from one of the many machines that are located in the arrivals hall (beyond the first row of shops), or, if your baggage is taking its sweet time, the machine in the corner of the baggage claim area. (These are 2 meter high machines colored bright yellow and dark blue.) They do take credit cards, but only ones that have a chip. They may or may not accept European debit cards with or without a chip. Some of the machines accept coins, but not bank notes. You can of course also buy tickets at the ticket counter located in the arrivals hall (to the left of the ticket machines) but there unchipped credit cards aren't accepted either. So first get cash from an ATM or one of the many money changing outfits. (Also make sure you have AT LEAST 20 euros in cash on you at all times to pay for small stuff. 50 is better. ) If you're going to travel back early, you'll want to buy a ticket for the return trip at this point, ticket offices aren't always open very early or very late. You can get a ticket for the day of your return trip or one without a date. In the later case, you need to validate it by sticking it in a small yellow box that should be on the platform somehwere. Another option is to get an OV-chipkaart (OV = public transport, chipkaart = chip card.) They cost 7.50 euros and function as an electronic purse. So you need to charge the card with some money first, and then you can pay for your trips by checking in when entering train or metro stations and checking out when leaving stations. In trams and busses, you check in and out when entering and leaving the vehicle. When paying with the OV-chipkaart the trip to Maastricht is 22.15 euros, so you make back most of the 7.50 you paid for the card. The card is valid for 3 - 5 years so you can use it on subsequent trips as well, or give it to someone else. If you're just going to use it for the train, it's probably not very useful to get an OV-chipkaart. However, if you're going to visit Rotterdam or Amsterdam and plan to use public transport there (which you should, driving is frustrating and parking is expensive there) you need one as the OV-chipkaart is the only form of payment for busses, trams and metros in those cities. (There are also single trip tickets and day tickets.) You can add more credit to an OV-chipkaart using the NS ticket machines or have this done at the ticket counter, and there are machines scattered elsewhere that can also do this and may even take chipless
Re: IETF 78: getting to/from/around Maastricht
A paper train ticket is 25 euros; if you want to go to Maastricht Randwyck is the same but it needs to say Maastricht Randwyck on the ticket. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: open protocols
On 25 mei 2010, at 20:17, todd glassey wrote: The IETF does NOT own the underlying license rights to TCP/IP in ANY WAY. For the record TCP/IP actually probably still belongs to the US Government as it was originally produced under a Department of Defense contract with BBN about 40 years ago and nothing about its ownership has ever been handed over to anyone that I know of. Interestingly, RFC 793 doesn't appear to have any copyright claims. I'm not sure when it stopped being necessary to have one of those in order to be granted copyright in the US. I'm not sure though how many rights one can hold to a protocol separately from the copyright on the specification. Obviously independent implementations don't violate any copyrights, and I'd be surprised if there were trademarks or patents on TCP. If those ever existed, the trademark obviously wasn't defended and the patents have expired. (BTW TCP, IP and family are from ~ 1981, postdating the original ARPANET NCP protocol by a decade.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Meeting Room Space Availability Policy
If you go through all of the trouble to say all of this: On 18 mei 2010, at 21:46, Ray Pelletier wrote: The IAOC has adopted a Meeting Room Policy regarding the use of available IETF meeting room space, the approval process, and charges for the rooms and services based upon the category of the group requesting the room. An IETF Meeting requires nearly 4,000 square meters in meeting space for working group sessions, the NOC, terminal room, offices, storage and other specific uses. Occasionally not all of the space is needed for every part of the meeting, or the IETF controls additional space. When there is available space, and space is available in non-meeting hours, the IAOC desires to make it available in a manner that considers the work of the IETF, fairness, and its expenses. Then why make us click on the link for the rest: The policy can be found on the IAOC site at: http://iaoc.ietf.org/docs/Meeting-Rooms-Policy-05-13-10.txt Especially after dropping the expenses cliffhanger. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: open protocols x proprietary protocols
On 17 mei 2010, at 22:05, victor nunes wrote: For example, if I wanted to write a book about an article or book on some proprietary protocols, I'd have to ask permission for the patent holders of their protocols? You don't need to ask for permission to write a book if the country you're residing in has freedom of speech. Be careful with including material from third parties, though, you often need permission for that. Other than that you want to be clearly either fiction or fact, true fiction or untrue facts can cause trouble. That being said: patents are published so no problem there. Some companies only provide information under NDA or forbid reverse engineering in their license, so if you publish such information they can get upset. Even more so if you publish trade secrets. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On 10 mei 2010, at 5:01, ty...@mit.edu wrote: I talked to a cab driver in Boston, and he's not very happy with credit cards, because he was forced to use a new system for credit cards, and it takes what he considered an unfairly large percentage when customers pay by credit cards. And that's why credit cards are so evil. I understand there are often provisions that sellers can't charge a premium for credit card payments to make up for the commission so in places where creditcards are common EVERYONE pays more because of credit card commissions. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On 8 mei 2010, at 1:50, Glen Zorn wrote: More than once, I _have_ asked the driver specifically if he accepts credit cards (the advertised policy notwithstanding) only to have him refuse it upon arrival... Curious way to engage in commerce. Where was this? BTW: I'm typing this from Schiphol airport. I just went to the train ticket counter, and they have big signs posted everywhere that they only accept PIN-enabled credit cards. And cash, of course. Note that on http://www.ietf78.nl/ it says that the railway ticket machines accept cash, but that's only barely true: only some of them do, and then only in the form of coins. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Public musing on the nature of IETF membership and employment status
On 6 apr 2010, at 18:16, Mark Atwood wrote: Cisco, IBM, MCI, or Linden Lab are not a members of the IETF. No agency of the US government, or of any other government, is a member of the IETF. No university, non-profit, PIRG, PAC, or other concerned citizens group, is a member of the IETF. Only individual people can be members of the IETF. And membership is mostly defined as who shows up on the mailing list and who shows up at the meetings. True enough, but that's only one side of the equation. Cisco, IBM, etc, etc as a rule don't send their people to the IETF to support the greater Minneapolis area economy or other alturistic reasons: they want their people to get stuff done at the IETF. As such, an IETF participant's affiliations have relevance, and should be clear to all. Considering that, it wouldn't be the worst idea to have everyone post mailing list messages from an employee email address. Then again, I don't need that kind of spam exposure on even more email addresses... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On 1 apr 2010, at 2:56, Phillip Hallam-Baker wrote: In theory it is possible to use a US issued credit card in Europe. In practice, forget it unless you are willing to face the embarrassment of 50% of places declining your card. :-) What you have to remember is that in many European countries, including the Netherlands, there is no tradition of credit card use. Rather, people use debit cards. Of course restaurants, hotels etc that cater to tourists accept them, and these days more places that sell expensive items do as well. But I would be very surprised to find a super market in the Netherlands that accepts credit cards. And credit cards are also not universally accepted in restaurants (the bigger / more expensive, the more likely they accept credit cards). So you really need to carry enough cash to at least pay for a meal and a train ticket or taxi ride. You can find ATMs with the Maestro and Cirrus logos all over the place, so this shouldn't be a problem. (Although because of lack of regulations that forbid this, you're likely to pay a hefty commision for cash withdrawals and of course your bank has to allow them.) My experience in the UK is that outside London you are very likely to find that the only cards they accept are chip and pin cards. I don't think places in the Netherlands that accept credit cards require a chip, mine didn't have one until last year. Without having been able to test this, I'd say that in any place that accepts credit cards in the Netherlands (logos on the window) you should be ok: since Dutch don't use them much and rarely if ever depend on them, places that accept them do so mainly for the convenience of international travelers. Also note that the most widely accepted credit card type is Mastercard, followed by Visa. With other cards, your milage may vary even more. I have a UK card just so I can spend money in the UK. Even when traveling in the EU with a card from a different EU country you can encounter refusals in non-tourist places, but at least when it works the charges (if any) are reasonable. (In fact I can withdraw money for free from all Spanish ATMs with my Dutch debit card but with the Spanish one, ATMs from banks other than my own cost me 50 cents.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: stable, continuing meeting mailing list?
On 1 apr 2010, at 01:12, Ole Jacobsen o...@cisco.com wrote: On the other hand, generic discussions about meeting planning, travel tips and Ole's Guide to Japanese Gadgets might be more appropriate on a permanent list, right? If only the IETF had a list for general discussions... As for the per-meeting lists, mail filtering etc would be easier if it was the same list each time. People could then either permanently subscribe or choose to be auto-unsubscribed after the meeting. Note that I still would have posted my message to the general discussion list because the point was to provide info to people deciding if/how to travel. Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On 30 mrt 2010, at 10:15, Marco Davids (Prive) wrote: http://www.ietf78.nl/. Ok, one thing: I strongly recommend AGAINST purchasing any _Dutch_ train tickets before you travel. (This does not apply to international train tickets!) The Nethelands is currently making a transition from paper tickets to RFID card based payment (OV-chipkaart, similar to the London oyster card) for all forms of public transport. Depending on how this proceeds the coming months it may be both cheaper and more convenient to get one of those RFID cards to pay for your train journey as well as the bus in Maastricht and public transport elsewhere in the Netherlands, especially Rotterdam (all forms of public transport) and Amsterdam (the metro) where paper tickets are no longer valid. I'll prepare information about all of this as soon as I know the transition status during the IETF week. And in any event, there are no early booking / online booking discounts for Dutch train tickets, and buying online with Dutch Railways requires the iDEAL payment system that only Dutch banks use. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On 30 mrt 2010, at 15:39, Basil Dolmatov wrote: OV-chipkaart logo is already seen on some ticket machines, so I would be glad to get an advice where and how these chipkaarts can be bought and where it can be used except for train tickets purchase. (Plural of chipkaart is chipkaarten, or use chipcards, but please not chipkaarts. In Dutch most words are pluralized with -en, some with -s.) The OV-chipkaart (OV = openbaar vervoer = public transport, kaart = card) is supposed to be rolled out in the province of Limburg, of which Maastricht is the capital, this summer. If that happens, I will recommend anyone traveling through Schiphol to get one. The existing paper bus/tram tickets are not all that user friendly, some trips require invalidation of two strips, others three. With the chipcard you check in when you enter the bus and check out when you leave, no need to know about zone boundaries etc or master Dutch/Limburgs to the degree that the bus driver understands you when you tell him/her your stop. The chipkaart costs 7,50 euros but the train trip between Schiphol and Maastricht is 5,85 euros cheaper with the chipkaart than with a paper ticket so you still come out ahead. You can get one from the ticket machines I believe but it probably makes more sense to buy one at the ticket counter and ask them to charge the card with the right amount of credit so you don't run out too soon or get stuck with too much left. You also need to specify whether you want to travel first or second class before you can use it in the train. I'll compile detailed instructions in july. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
Note: I unintentionally wrote off some German airports that _may_ be suitable for travel to Maastricht, such as Cologne/Köln. But be careful with any of the smaller airports in the region, check ground transportation before you book or you may be in for nasty surprises. On 29 mrt 2010, at 4:37, Michael Richardson wrote: Richard IAOC: I had been getting used to the idea of Maastricht, Richard with it being historic, nice city center and all. Richard Iljitsch's observation makes me wonder if we learned it appears one has to cross the river? Iljitsch can you confirm the end points are reasonable? Looking at the street map, I think that there are might be many closer restaurants, such as on Wycker Brugstraat. I wasn't in Dublin, so I don't know the issue there. Was the problem like in Vienna? In Dublin, we were outside the city, with travel times by car or bus of 30 or more minutes. However, some impromptu lunch facilities were set up at the venue so those who didn't have time for a real lunch could buy a sandwich or two. I don't remember what I did for lunch in Vienna, but there there was good public transport. In Maastricht the situation will be different from both: because it's a small city, public transport isn't very high frequency / high capacity, but we'll be within walking distance of the city center, so for _dinner_ this shouldn't be a problem. It's just that in my opinion, it's not doable to have a decent lunch within 1.5 hours if you have to walk 4 km. (Also note that going out for lunch isn't as common in the Netherlands as elsewhere, not every restaurant serves lunch.) Like Henk said, the Vrijthof is considered the center square of the city, but you don't have to go all the way there, once you get closer to the main railway station there should be places to eat. And the maas (meuse) river isn't quite as wide here as it gets in Rotterdam, it doesn't take the whole day to cross it. :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Advance travel info for IETF-78 Maastricht
Even though many of you are still fighting jet lag, it's never too soon to start thinking about the next IETF meeting! Below some musings on how to get to Maastricht from various airports to aid those who want to book their plane and possibly train tickets. Lunch: But before that: Maastricht is the Netherlands' 19th largest city, about the same size as Ann Arbor. (Just over 100k inhabitants.) The MECC conference center is 2 - 3 kilometers from the city center, where the restaurants are. That's too far to walk for lunch, and I doubt the city busses or taxis are up to the task of transporting a thousand hungry IETF'ers back and fro in the alotted time, either. So it would be very good if lunch arrangements similar to those in Dublin could be made. Ground transport: Maastricht is located in the far southeast of the Netherlands, 215 km (by road) from Amsterdam. The city is located on the Belgian border and is also very close to Germany. There are some smaller airports closer to Maastricht than the ones mentioned below, but those don't serve many destinations and don't connect to the rail network so more hassle and as much or more time to reach Maastricht despite the shorter distance. Only consider these smaller airports if you know what you're doing. You can of course rent a car at one of the airports and drive to Maastricht, and even commute between the MECC and your hotel by car if the hotel is located outside the inner city, but you'll probably need to get into the city for dinner anyway and being a few thousand years old, Maastricht's city center isn't really built for cars. The most convenient airport to use would be Schiphol (Amsterdam) airport. From there, it takes about 2 hours, 35 minutes with one change to get to Maastricht by train with a connection every 30 minutes. A second class one way ticket is 27.50 euros. The last train from Schiphol to Maastricht is at 22:16. The first train to Schiphol arrives at nine. A good alternative is Brussels, from where Maastricht is about two hours with one or two changes and one connection per hour with regular national and international trains. The last connection to Maastricht is at around 21:39. The first train to Brussels airport arrives at nine on weekdays, ten on weekends. There are also a few high speed train connections which save you 30 minutes. If you're arriving in Europe through Frankfurt or Paris, it may not make too much sense to first connect to Amsterdam or Brussels and then sit in a train for a few more hours. You may as well take the train directly from these airports to Maastricht. However, consider that missing train/plane connections is your problem, while plane/plane connections are the airline's problem. (Financially, at least.) From Frankfurt, there is one connection per hour (weekdays) or one every two hours (weekends) that takes 4 hours, 46 minutes with regular national and international trains. The last connection to Maastricht without high speed trains leaves at around 18:22. The first connection to FRA without high speed trains arrives at 13:36. From Frankfurt it is (of course) faster to take a high speed train, and from Paris it's the only option. The downside of high speed trains is that you can't just hop on like on a regular train, you need to book or reserve a seat on a specific train. Also, they run less often so if you miss one, you're in big trouble. Also check prices before you book (usually available 90 days before the travel date), international trains in general and especially high speed trains can be quite expensive. From Frankfurt, there is an ICE connection several times a day that takes between 3 hours and 3 hours 41 minutes with 2 or 3 changes. The last connection to Maastricht is at 21:09. The first connection to FRA arrives at 10:16, 11:51 on sundays. From Paris, there is a thalys connection every two hours or so in the weekend and a bit more often during weekdays. The journey takes between 3 hours, 15 minutes and 4 hours, 10 minutes, with one or two changes. The last connection to Maastricht is at 20:04 on weekdays and 18:49 on weekends. On weekdays, the first train to CDG arrives at 10:44, on the weekends 11:36. You can also get from Heathrow to Maastricht in 5 to 6 hours with 2 or 3 changes, but as the last connection from Heathrow is around five and from Maastricht the first one arrives at around noon (two hours later on weekends), this seriously limits your flight options. The best place to investigate rail connections is http://www.bahn.de/ You may also want to check the website of NS, the Dutch railways: http://www.ns.nl/ (but only for Dutch trips, their international planner is incomplete and will often only show longer and more expensive options) and http://www.maastrichtbrusselexpress.nl/ I have no recommendations on where to book train tickets. From Schiphol, the recommended way to get to Maastricht is with a change in Utrecht. Don't
Make HTML and PDF more prominent, was: Re: Why the normative form of IETF Standards is ASCII
On 19 mrt 2010, at 5:05, John Levine wrote: xml2rfc does a pretty good job of capturing what needs to be in an RFC, so that is the strawman I would start from. 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. On 19 mrt 2010, at 2:04, Tim Bray wrote: On Thu, Mar 18, 2010 at 12:24 PM, Iljitsch van Beijnum iljit...@muada.com wrote: So far the only thing I hear is assertions offered without any foundation that the current format is problematic OK, one more time, let me enumerate the problems with the current format. I agree that you may not perceive them as problems, but they are problems for me: 1. I cannot print them correctly on either Windows or Mac. 2. I cannot view them at all on the mobile device These two issues can easily be solved by using the PDF or HTML versions. Any paginated ASCII can be turned into a PDF easily and automatically. There are different HTMLizations of RFCs, some better some worse. Creating an HTML version is harder than a PDF version without an xml2rfc source but for most RFCs there is a decent HTML version available somewhere. The PDF versions can be obtained from the RFC Editor if you search specifically for them, but in most places only the text versions show up. It would help a lot if the HTML and PDF versions were easier to find. Maybe the secretariat could put this on their todo list? 3. I cannot enter the name of an author correctly if that name includes non-ASCII characters. But even if you could, would you? I can't do anything useful with names written in anything other than latin characters (well, maybe also Greek). I wouldn't even know how to type them if I wanted to search for them. So at the very least all names would still have to appear in latin script and the non-latin form would be extra. Is the tiny benefit of having the real name there as a non-normative extra really enough to change what we've been doing for 40 years? 4. I cannot provide an actual illustrative working example of the use of non-ASCII text in Internet Protocols. Correct interpretation of things like UTF-8 is highly dependent on context. On many systems a plain text file with non-7bit-ASCII characters won't be displayed as intended by default. So it would be necessary to go to HTML with #; encodings of these characters or PDF to be reasonably sure they show up correctly. To me, PDF is unacceptable because it's even harder to display on devices other than computers with large screens or paper and it can't be decoded without complex tools. And switching to HTML just for this purpose isn't worth it to me. But then, I've never written a draft that required non-ASCII characters so that's easy for me to say. ___ 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
On 19 mrt 2010, at 12:02, Dave Cridland wrote: Why care about a normative output? You change the subject to talk about using non-normative representations already, why care about a normative output *at all*? You have a point. But it's in the subject line... Let's concentrate on a normative format, and ideally making that format editable directly. Right, because that is the thing you need to do most often with the normative form of the document. /sarcasm The most important feature of the normative version is that it is unambiguous. That means that the software layers to view that version must be as few and as simple as possible. 3. I cannot enter the name of an author correctly if that name includes non-ASCII characters. But even if you could, would you? I don't think in itself it's a huge deal. I just think it's crushingly embarrassing. The IAB made a clear statement that we need i18n support, yet over a decade after RFC 2130 or RFC 2825, the RFCs themselves still have a strict ASCII limitation. Sure, that wasn't mentioned at the time, but does nobody else find this plain shameful? Not at all. Requring all users around the world to use latin script in their URL bars and email addresses is a very bad thing. So all user serviceable parts of internet standards must support scripts used around the world. But that's a very different thing from what the IETF should do for its internal business. We already restrict our communications to the English language. The further restriction that publications only contain 7-bit ASCII can be argued on both sides, but is hardly shameful. It's just a matter of efficient operation. I'm named after Пётр Ильич Чайковский, but the Dutch government only accepts names in latin characters. If countries can impose that restriction, the IETF certainly can. On 19 mrt 2010, at 18:06, Henning Schulzrinne wrote: Pragmatically, one could simply state that one form (say, good-ol ASCII, to avoid endless debates and for historical reasons) was authoritative and that others were best effort versions of the same text and that any deviations and omissions were accidental and should be brought to the attention of the appropriate authorities. Exactly. And then provide links to the PDF and HTML versions on an equal footing with the text version so people can easily select the version that best suits their needs of the moment. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
On 18 mrt 2010, at 2:43, Richard Barnes wrote: +1 Making the XML normative would be an abomination. The XML in itself can't be interpreted by a human to the level needed to create a compliant implementation, although it deceptively looks like maybe it could. Of course human readability also doesn't exist for pretty much anything other than text or the simplest of HTML, in itself this isn't a show stopper. But there is no standard way of converting xml2rfc into something that humans can interpret unambigously. Practically, the only way to do this is with the xml2rfc tool, which is non-standard, only partially documented and very hard to run for most people. There have also been times during which the released version was unable to convert the XML files that were actually being used inside the IETF. And of course there are no existing RFC for which there is an xml2rfc XML file that you can run through xml2rfc and obtain the exact ASCII version of that RFC. Older RFCs are formatted in ways which are completely incompatible with xml2rfc, so it would be impossible to have all RFCs be available in one format if XML is adopted for future RFCs. If we really want to do something in this space first of all we need to agree on the problem, then on the requirements and THEN we can have a useful discussion. So far the only thing I hear is assertions offered without any foundation that the current format is problematic, while every personal computer operating system sold (or given away for free) the past decade can display it without the need to install additional software. That's a pretty good result for files which date back as long as 40 years. Good luck finding any other document format of the same age with that property. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
On 18 mrt 2010, at 20:59, Julian Reschke wrote: The XML in itself can't be interpreted by a human to the level needed to create a compliant implementation, although it deceptively looks like maybe it could. Of course human readability also doesn't exist for pretty much anything other than text or the simplest of HTML, in itself this isn't a show stopper. That is simply incorrect, which can easily be checked by looking at the XML source of a spec. People make mistakes implementing today's text. If they have to implement from XML source where they have to interpret things like escape codes and numbered lists (just to mention the first two things that come to mind) in their head this is going to be much worse. There is at least one other implementation that can be used by everybody who's got a current browser So now I have to have a working network connection to read an RFC? What if the site that hosts all this goes down? What if someone wants to read a spec 20 years from now? it would be impossible to have all RFCs be available in one format if XML is adopted for future RFCs. Yes. How is that a problem, exactly? Because this doubles the amount of effort needed to be able to read RFCs. And if old RFCs can be in text, why not new ones? And if some RFCs are text, why not derive text versions of the XML ones too, so there are text versions of all of them? And if there are text versions for all RFCs and XML versions of only some, why not make the text version authoritative? Oh wait... That's a pretty good result for files which date back as long as 40 years. Good luck finding any other document format of the same age with that property. That may be true, but that features comes with drawbacks. Drawbacks that we can all agree on? Sure, RFCs don't look too pretty, and their hard line and page endings are very annoying because they never fit the screen or paper that you happen to use. (Aside: PDF is much worse in this regard.) But pretty much all RFCs can be viewed in HTML versions which don't have these problems by anyone who cares. Being able to have names and examples in non-latin characters would be nice, but for names this is just a cosmetic thing with compatibility issues that make it not worth the trouble, and with examples it's dangerous to depend on correct display of anything that isn't 7-bit ASCII because it's still quite easy to end up with something that's incorrect or doesn't show. The ability to use graphics would be helpful but would have severe consequences for the file format, having to use multiple files to make up a single RFC would be problematic (ASCII, HTML with images) and single file formats aren't trivially decoded. Images are also very hard to edit, making collaboration and especially updating RFCs much more difficult. And the inclusion of images reduces the number of devices that can display an RFC significantly. (Line printers, text only displays and remote login sessions are out, hand held devices also to a large degree because the screens probably don't have enough resolution.) I guess plain ASCII isn't so bad after all. Would be nice if we could get rid of the pagination, though. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What day is 2010-01-02
On 14 mrt 2010, at 1:09, Phillips, Addison wrote: There is also a difference between regularized usage and formats derived by well-meaning people based on their own experience (i.e. a European might very well think first of ydm, being used to seeing the day preceding the month). No way. Year-month-day makes sense because it matches the way we parse numbers. Day-month-year makes sense because that's the usual way to write it down. All other ways to do it, including using only two digits for the year, are confusing, ambiguous or both. For instance, even if I know that 4/7 is supposed to be the seventh of april it confuses me, and often you don't know so it's also ambiguous. I know that some people feel it's important to make the IETF website easier to grok for outsiders. But if someone can't figure yout 2010-01-02 then maybe they're not our audience. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the normative form of IETF Standards is ASCII
On 12 mrt 2010, at 6:58, John Levine wrote: Indeed, I know plenty of people these days who have no idea today how to produce an ASCII file with only tab, CR, and LF formatting characters. Type. Save as text. How hard is that? I have actually written a few drafts that way. The text part isn't hard, but the hard breaks at every line are, and the hard breaks at every page even more so. Tools do create those don't exist in today's world. The current process uses input and output formats that are similar enough that people wrongly think they're the same, even though of course they are not. Many people seem to assume that if we picked a new output format, we would necessarily change the input format to be the same as the output format, which I think would be a terrible idea. The input formats need to be reasonably easy for non-experts to create, Which it is not. xml2rfc is very hard to use for anyone who has otherwise no experience with XML just because it's XML (the proper nesting and terminating are hell) and also because at least 50% of the xml2rfc commands aren't documented. I don't understand why we would even need to discuss the output formats, you can get HTML and PDF without trouble, even though the text version is authoritative. It's the input that's the problem. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What day is 2010-01-02
On 17 mrt 2010, at 17:02, Michael Edward McNeil wrote: (Although the exposure to non-standard ways of doing things may make this harder for Americans.) Since Americans habitually use month-day order anyway, why would -MM-DD be especially difficult for them? It's Europeans and others who typically use day-month order that would seem likely to incur difficulties -- except that putting the year first is a pretty glaring clue that the order shouldn't be regarded as it usually is for them. Absolutely. But Americans don't expect this kind of stuff to make sense, because they're used to having a different way of measuring everything, while in the rest of the world we're used to the metric system so we assume things make sense. So an American wouldn't necessarily consider -dd-mm inconceivable while people from elsewhere probably would and just assume -mm-dd. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: What day is 2010-01-02
On 17 mrt 2010, at 14:59, Yao Jiankang wrote: But if someone can't figure yout 2010-01-02 then maybe they're not our audience. there are two kinds of audience: those who understand 2010-01-02 by usual way and those who understand 2010-01-02 by unusual way. your logic reasoning seems to be simlar to: if you don't understand the ietf draft (ietf rfc, ietf discussion, .), you are not ietf audience. There needs to be a healthy balance between the effort expended to make something clear and the effort expended to understand something. RFCs can get pretty complex. Someone who can't figure out what 2010-01-02 is supposed to mean with all the resources of the internet available to him/her is going to have a hard time understanding RFCs. An anthropologist may approach the situation open minded and don't make any assumption about whether this is -mm-dd or -dd-mm, but anoyone with even the slightest exposure to engineering will understand that the only logical continuation of - can only be mm-dd. (Although the exposure to non-standard ways of doing things may make this harder for Americans.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Towards consensus on document format
On 13 mrt 2010, at 21:54, Phillip Hallam-Baker wrote: So in the hope of finding consensus here, lets see what people's position actually is A) The format issue does not matter B) The format issue matters a little to me and I prefer the teleprinter format C) The format issue matters a lot to me and it MUST be teleprinter format D) The format issue matters a little to me and I prefer the HTML format E) The format issue matters a lot to me and it MUST be HTML format Haven't read the discussion until now (will do that tomorrow) but let me add F and cast the first vote in favor of it: F) HTML that reverts back to usable ASCII (although I'm willing to live without headers/footers and the whitespace may look a bit different as long as it's self-consistent) when everything between and is removed from the file and a very limited set of *; sequences has been searched and replaced. No images because those can't be viewed without non-trivial tools and they are extremely hard to modify from the published version. I am in class E. I find being required to edit documents in teleprinter format to be very insulting to me personally. I take a great pride in my work and I do not like being forced to present it in a format where the principle justification for it appears to be 'because we can force you to do it our way'. replace document format with xml2rfc xml format and I'm with you 100%. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Releasing xml2rfc 1.34pre3?
On 5 jul 2009, at 15:20, Carsten Bormann wrote: On Jul 3, 2009, at 19:49, Andrew Sullivan wrote: 1. The recent boilerplate/process-change events have resulted in a situation where the most-recommended tool for preparing IETF documents does not work at all in its stable version. To me, 1.34pre3 appears to be exactly as stable as 1.33 (modulo the instability inevitably introduced by the 5378 train wreck). Would it help to simply call it 1.34 now? I guess the last round of whining about xml2rfc wasn't sufficient in scope and volume, I'm sure the upcoming one will best it on both counts. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
On 16 sep 2009, at 18:40, IETF Member Dave Aronson wrote: Ten years out, who knows? Maybe. However, even then, that will affect almost exclusively devices with *public* IP addresses. The gazillions of devices behind NATs may also need to speak IPv6 when connecting to the outside world, but will have little to no need to give up IPv4. Neither will those on completely private networks. What's the point of running IPv4 when you can do everything you need to do over IPv6? (Note that it works the other way around, also...) IPX, DECnet, AppleTalk etc disappeared from view pretty quickly as IP conquered the world. But before the bury IPv4, it would be a good signal to make IPv6 a full standard. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 standard?
On 12 Sep 2009, at 1:46 , JORDI PALET MARTINEZ wrote: For this and other RFCs, we started some years ago the work at http://www.ipv6-to-standard.org Just waiting for the IESG to take on it ... So? What's the holdup? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IPv6 standard?
Hi, It occurs to me that a small but potentially meaningful thing that the IETF could do to push IPv6 adoption is move RFC 2460 from draft standard to standard. Iljitsch ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Actual IPv6 deployment observed
On 27 jul 2009, at 9:43, Arnt Gulbrandsen wrote: This must mean that silently enabling IPv6 increases the number of people for whom IPv6 works by a factor of around 100 (from 0.01% in the general population (http://asert.arbornetworks.com/2008/08/the-end-is-near-but-is-ipv6/ said 0.01%.) The 0.01% they talk about is TRAFFIC, not USERS. And it's bogus anyway. For instance, just the traffic through the AMS-IX is many times more than what they measured: http://www.ams-ix.net/technical/stats/sflow/ (Note that they use meaningless lying graphs = don't start at 0.) At AMS-IX, native IPv6 traffic is now 0.3% on average, up from 0.1% a year or so ago. When I did some web bug measurements years ago my results where about 0.16% IPv6 users (1 in 666). Last year, Google got 0.25%. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Actual IPv6 deployment observed
On 27 jul 2009, at 16:29, Danny McPherson wrote: The 0.01% they talk about is TRAFFIC, not USERS. And it's bogus anyway. Not that I want to have this discussion here again (folks should revisit the archives) This is what I had to say about it: http://arstechnica.com/old/content/2008/08/researchers-ipv6-traffic-a-mere-0-0026-percent-of-total.ars At AMS-IX, native IPv6 traffic is now 0.3% on average, up from 0.1% a year or so ago. When I did some web bug measurements years ago my results where about 0.16% IPv6 users (1 in 666). Last year, Google got 0.25%. To your point, that Google stat was users,not traffic. Very true, my apologies. I suspect their traffic rates are much lower than that :-) They don't publish records without prior arrangement so I would tend to agree. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Actual IPv6 deployment observed
On 26 jul 2009, at 12:45, Arnt Gulbrandsen wrote: I quote from thepiratebay.org home page: IPv4 21.613.113 peers (10.992.697 seeders + 10.620.416 leechers) in 1.969.865 torrents on tracker. IPv6 210.410 peers (115.584 seeders + 94.826 leechers) in 174.895 torrents on tracker. Most numbers are about 1%, and about 9% of torrents contain one or more IPv6-capable peers. Ooh aah. You do have to understand that IPv6 support was available in BitTorrent clients for a long time, but then the Pirate Bay deployed trackers (servers) that were incompatible with the existing clients, so only people who both have IPv6 and a recent IPv6-capable client are in those numbers. I had to null-route the PB IPv6 address to get my old client to work again over IPv4... Another example of how NOT to migrate from old stuff to new stuff. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 14 jul 2009, at 11:20, Doug Otis wrote: For a third-party application to interpret the changing Word document format, even in XML form, would require extensive and ongoing support. In principle, yes. In practice this would probably not be a huge deal compared to what needs to happen to conform to new ideas from the lawyers. Obviously Microsoft didn't come up with an XML file format and then push it through standardization to do all of that again a few years from now. We can expect the format to be extended, but the basic stuff will probably remain the same for a long time. (And we only need the REALLY basic stuff here!) This solves the problem that converting anything else into XML2RFC a reverse lossy process: XML2RFC needs more than what other formats can supply so automatic conversion (from, for instance, Word) is impossible. is a genuinely useful and productive counterargument against the whole word2rfc concept. Disagree. The goal would be to generate RFC and ID documents. Directly from .docx files? Requiring XML2RFC intermediaries negates the benefit of using Word. I disagree. If it were possible to generate XML2RFC format from Word format that would be extremely useful, because that way people who can work with Word can generate XML2RFC that can then be used by people who work in that format, including the RFC editor. But as I've said before, the semantic markup in XML2RFC makes it impossible to create a working XML2RFC file from an input that doesn't have the same semantic markup. Although tagging semantics can probably be a bit more pleasant in a WYSIWYG tool than in XML source, it still has all the documentation and version breaking issues that XML2RFC has, so that doesn't really buy us much. Iljitsch view of XML2RFC intermediaries is not practical, but Word2rfc is not impossible when the bundled program language is used. I was talking about a new intermediate format. What I'm thinking of is a constrained HTML. HTML can be used both as input and output in word processors and text editors with only minimal extra steps, if any. A lot of those generate atrocious HTML, but this can easily be fixed by removing everything that doesn't conform to the constraints. Converting from XML2RFC format to HTML would be lossy, so converting in the other direction would entail some manual work. But for the basic text in the middle a 1-to-1 mapping would be possible, which would help a lot. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 13 jul 2009, at 21:56, Douglas Otis wrote: Visual Basic would represent a more likely tool, since it is already supported by the Word application. Only in some versions. In the latest MacOS version it's not supported. This makes one wonder whether there could be a better way. I think a better way would be to create a new intermediate format that can both be an input to generate XML2RFC code _to_ as XML2RFC code _from_, as well as HTML and the current RFC archival format. This solves the problem that converting anything else into XML2RFC a reverse lossy process: XML2RFC needs more than what other formats can supply so automatic conversion (from, for instance, Word) is impossible. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Avoid unknown code sources (was: Re: RFC archival format)
On 9 jul 2009, at 1:56, Douglas Otis wrote: The concern was voiced in opposition to suggestions for using Word input files as a means to generate inputs for I-D or RFC generation utilities. Nobody suggested that. I said that it would be useful to be able to use a standard issue word processor to write drafts. As I explained in a subsequent message, what I meant by that is any word processor that can generate a document with styles. Word is one of those word processors, but certainly not the only one, and you'll never hear me recommend Word for anything. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
IETF languages, was: something about RFCs
On 9 jul 2009, at 18:15, james woodyatt wrote: B) is open for debate: what precisely should be the set of primary natural languages used in IETF documents? Should it continue to be English only? I'd very much prefer to see *that* discussion vigorously deferred while our archival format continues to be the largest practical obstacle to multilingualism. There are two things that together make it completely impossible to adopt more working languages: 1. We don't have any other languages in common than English 2. We don't have the money for translation/interpretation services Dus als we naast Engels ook andere talen gaan gebruiken betekent dat dat de niet-Engelse documenten maar door een deel van de IETF- participanten gelezen kan worden, wat natuurlijk niet de bedoeling is. Or: So if we start using other languages in addition to English then the non-English documents can only be read by part of the IETF- participants, which of course defeats the purpose. Now I'd be very happy to be able to conduct IETF business in Dutch, but I'd be very much opposed to having to learn a new language to participate in the IETF. It took me long enough to learn English... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 7 jul 2009, at 12:25, John C Klensin wrote: The questions, or at least a subset of them, are important. But we never manage to reach consensus, partially I think because we make different assumptions about what is important, and that wastes a lot of time. If we really want to make progress here it's not going to happen by reaching rough consensus after a long discussion, but by a (very) small group of people getting together and coming up with something that improves upon the current situation for (pretty much) everyone, rather than optimize for one particular way to interpret the state of the universe. The good thing is that the current situation leaves so much to be desired that this should actually be doable. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: xml2rfc is OK ( was: Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format)
On 7 jul 2009, at 15:30, Julian Reschke wrote: Thus, you can simply open the XML in the browser, and let the browser convert to HTML. Notwithstanding everything else I've said, this is pretty cool, makes it much easier to find problems in the XML. Is this kind of stuff covered in the XML2RFC intro at IETF-75? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 7 jul 2009, at 22:42, John C Klensin wrote: The good thing is that the current situation leaves so much to be desired that this should actually be doable. I do not believe that we can reach agreement on even the last statement. I think this discussion shows that our starting assumptions about what is important, about how to count (pretty much) everyone, etc., are divergent enough to make an effective process like the one you outline unlikely. The points that you make in the rest of your message are mostly valid, but I think they can be addressed by showing people that if we take a few steps in the right direction, they at least get something that is better than today, so most people would be at least somewhat happy with that. I truly believe it can be done, and I'd be happy to take the time to make a start in Stockholm if anyone else is prepared to invest time. (We have a saying in Dutch: the soup is never eaten quite as hot as it is served = people are generally more reasonable than their intial positions suggest.) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 6 jul 2009, at 8:53, Yaakov Stein wrote: OK, here is what happens on my netbook using your method. What I see : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+-+-+-+-+ Hm, it's not supposed to break lines between pre and /pre even if they don't fit on the screen... Obviously ASCII art is created with screen / paper size assumptions built in. I never claimed I was able to get around that. My claim was that it was possible to create an HTML-ized form of the RFC format that would both be valid HTML and could be turned back into the well- known plain ASCII format by simply removing the HTML tags. Due to the difficulties in making good graphics and the issue of having a single RFC span multiple files in the case of HTML format with graphics I think we should stick with ASCII art in the general case even if we move to HTML as the archival format. But packet layout diagrams can be made with HTML tables, which would make them a little more flexible than ASCII art but on a really tiny screen those still wouldn't display very well. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 6 jul 2009, at 12:08, Melinda Shore wrote: Plus, there appears to be a certain amount of whimsy involved with rendering HTML and displays can be inconsistent, which 1) is one of the complaints about the current format, and 2) is undesirable for the display of technical specifications. I disagree with 2. Today, drafts and RFCs have a fixed format, that should render the same on all displays and in print (barring font differences, but I guess Courier is assumed). Although this format isn't particularly pretty and current mainstream tools can no longer create it, this format has a lot going for it: - pretty much everything that can classified as a computing device can display it natively - should the need arise to write an implementation for display software from scratch, that would be extremely trivial - no issues with copy/paste - compatible with lots of tools However, it has one big issue: it doesn't adapt to the properties of the display gracefully. (Or at all, really.) This is the part that would be easy to fix by adopting a very basic flavor of HTML. This would give us line wrap and the ability to use tables, but we'd lose the headers/footers. ASCII art could still be used as preformatted text. This type of basic HTML will render slightly differently on different implementations, but that's the point. Unless technical meaning is encoded in spaces and line breaks, this shouldn't matter. And even in basic HTML, it's possible to add class specifications etc that allow tools to apply more intelligence than would be possible with plain text. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
XML2RFC must die, was: Re: Two different threads - IETF Document Format
My apologies for the subject line. I'm very disappointed that the silent majority of draft authors isn't speaking up. I can't imagine that the vast majority of draft authors has absolutely no problems with XML2RFC. So I'm assuming they've been ignoring the thread, hopefully the new subject line will get some of them to chime in. If that doesn't happen I'll shut up and try to figure out why I have so much trouble with something that nobody else finds difficult. On 4 jul 2009, at 13:27, John Levine wrote: I think it's reasonable to assume that going forward the vast majority of users who read online documents will be able to use software that can reformat them in various ways. This tells me that although the publication form has to be readable in a pinch as plain text, it's more important that it's amenable to mechanical processing. Tidily formatted xml2rfc would be a reasonable candidate No, it's not. The problem with XML2RFC formatted drafts and RFCs is that you can't display them reasonably without using XML2RFC, and although XML2RFC can run on many systems in theory, in practice it's very difficult to install and run successfully because it's written in TCL and many XML2RFC files depend on the local availability of references. When those aren't present the conversion fails. The philosophy behind XML2RFC is to encode meaning in the XML wherever possible, rather than simply display text. There are several problems with that: 1. It makes it hard to write source files, because now rather than type Experimental at the top of the file, I have to know what XML2RFC looks for to determine the draft's status. Same thing with boilerplate, references, etc. 2. It makes it hard to read source files for the same reason. You can't read an XML2RFC formatted XML file without prior knowledge and get all the information that would be displayed in the final draft/RFC format. 3. It gets it wrong. XML2RFC knows that you create a name from an initial, a period, a space and a last name. So initial I and last name Van Beijnum becomes I. Van Beijnum. However, XML2RFC doesn't know that in Dutch, certain last name prefixes are capitalized if they appear at the beginning of the name (Van Beijnum) but not if they're in the middle because there are first names or initials: I. van Beijnum. This means that the makers of XML2RFC spent a lot of time making the tool require the authors to spend a lot of time to create something that is sometimes incorrect, with no means to correct the problem. An all-around waste of time. Then there is the problem with XML in general. Now apparently there are XML editors that can make sure you create syntactically correct XML without having to take care of all the details manually. But as someone who has otherwise no need to write XML, I'm not familiar with those tools. So I write my XML2RFC source by hand. The result is that I invariably get error messages that the section and /section tags don't match properly. This is a problem that is extremely hard to debug manually, especially as just grepping for section isn't enough: there could be a !--, --, /middle etc somewhere between a section and /section that breaks everything. First writing a source file and then compiling it into an output file is no longer something something that is familiar to most people. When I write anything other than a draft, I can simply select header level 2 and I know that everything will be taken care of. I don't have to explicitly tell my word processor where the text following a header level 2 ends, because the presence of another header makes that clear both to me and to the software. What we need is the ability to write drafts with a standard issue word processor. I'm sure that sentence conjured up nightmares of Word documents with insane formatting being mailed around clueless beaurocracies, but that's not what I mean. Word processors use styles to tag headings, text, quotes, lists and so on: the exact same stuff that you can do in XML but rather than having to think about it (especially closing all tags correctly) it happens easily, automatically and without getting in the way. (I can even change the style for an entire paragraph with a single menu selection or function key without having to find the beginnings and ends of that paragraph.) Formatting is then based on the style tags, with all explicit formatting aplied by the word processor removed. This is standard operating procedure in 99% of publishing. (The other 1% being scientific/engineering books where the authors send in Latex.) All the stuff that can't be handled by styles should just be copied and pasted from the boilerplate, without the need for tools to know about the structure of these things. (At least not in the draft stage, perhaps this can be useful in the final stages of RFC editing.)
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 5 jul 2009, at 15:04, Yaakov Stein wrote: Last but not least, just filter out anything between and and replace a few xxx; sequences and you're back to plain text. We could probably even format RFCs such that if you remove the HTML, you're left with the current ASCII format. You seemed to have missed the point. Almost all RFCs have ASCII art in them, [...] When you improperly break lines these figures are irreversibly corrupted, and in essence you lose a large part of the document. No, you're missing my point. That point is that a file like this: pIn order to be able to use the largest packet sizes under the widest range of circumstances, nodes SHOULD include a new MTU option in both neighbor solicitation and neighbor advertisement messages RFC2461./p pThe format of the neighbor discovery MTU option is as follows:/p pre 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length |R|T| Transport flags | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /pre Will display as follows if you remove everything between and (inclusive): In order to be able to use the largest packet sizes under the widest range of circumstances, nodes SHOULD include a new MTU option in both neighbor solicitation and neighbor advertisement messages RFC2461 The format of the neighbor discovery MTU option is as follows: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |Length |R|T| Transport flags | Res | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here are links to the examples in case they get lost in the mail: http://www.bgpexpert.com/drafthtml.txt http://www.bgpexpert.com/drafthtml.html http://www.bgpexpert.com/drafthtmlfiltered.txt So if you object to using a non-ASCII format because it will not be 100% readable 30 years from now, you should object to using the present format today. Wasn't that what I was doing? On 5 jul 2009, at 15:12, Yaakov Stein wrote: I personally started writing up a description of a packet loss concealment technique, but had to give up due to the formulas not being transcribable (I had no problem submitting a patent application instead). In TICTOC we are not even considering attempting any work that needs math, but rather leave it to other SDOs. It is considered a limitation of the system. So once those standards are published somehwere else, what kind of language do you use to implement them that allows mathematical formulas to be part of the code? In other words: anything that can be expressed in math symbols can also expressed in ASCII, programmers have been doing that for half a century. Annyoing, but it does have the advantage that once you have it in that format you don't have to worry about strange incompatibilities that make the symbols come out wrong. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: XML2RFC must die, was: Re: Two different threads - IETF Document Format
On 5 jul 2009, at 16:22, Dave Nelson wrote: I suppose if there were indeed a *standard* word processor, this might be feasible, but I think by standard issue you mean commercially available. Standard issue = standard, typical. I used it in the sense of any decent. Any word processor can create styles the way I talked about, such as Word, Pages, OpenOffice, just to name the ones that I know are still around. The only problem converting a style-tagged document to draft/ RFC format or whatever archival format we end up using in the future. The obvious way to do this would be to interpret the XML that each of these produce, but the problem is that they each have their own format, with little interoperation. Word 97 .doc format is the de facto lingua franca in the word processing world, but this is an inconvenient format. Rich text (RTF) format would probably be best. This format is fairly limited, but we only need the text itself and the styles so it should be more than sufficient. It's also a text- based format. On 5 jul 2009, at 18:01, Joel M. Halpern wrote: So I am very confused why you are asking us to kill a tool that was produced by volunteers, works very well, and that many people use by choice. You're right, I shouldn't use the word die. The blog post by ekr that I linked to in my first message talked about how XML2RFC has become a de facto requirement because of the outdated formatting requirements that can only be met with XML2RFC or even quainter tools. This is what I'm having problems with. Of course if people are happy with XML2RFC, that's fine. I have seen some folks arguing that we should make XML2RFC normative and mandatory. If they can figure out how to automatically and accurate convert the other mechanisms people use, then that can be considered. Ah, but that's impossible, unless you add an AI to the conversion tool that comes up with the semantic annontations that were never in the source. On 5 jul 2009, at 19:04, Doug Ewell wrote: The point about capitalizing Dutch names wrong is an important localization issue, since people's names are important, but treating it as a fatal flaw in the premise of encode meaning, not presentation seems to weaken the overall argument. It's a bug. It's not a bug, it shows that the basic premise behind XML2RFC is untenable. What we need is the ability to write drafts with a standard issue word processor. I'm sure that sentence conjured up nightmares of Word documents with insane formatting being mailed around clueless beaurocracies, but that's not what I mean. Word processors use styles to tag headings, text, quotes, lists and so on: the exact same stuff that you can do in XML but rather than having to think about it (especially closing all tags correctly) it happens easily, automatically and without getting in the way. (I can even change the style for an entire paragraph with a single menu selection or function key without having to find the beginnings and ends of that paragraph.) I fear this will run into the ground instantly, if the anti- Microsoft faction insists on a single standard issue word processor that is unfamiliar to most users. The same problems with learning to use a new tool will apply. It sounds like what people really want is a more comprehensive system that would allow I-D authors to use xml2rfc, roff, Word, LaTeX, or basically any tool they like, not a great policy reversal that replaces one mandatory tool with another. Given the level of effort involved and user expectations, especially concerning support for the latest updates to the IP boilerplate, this would be beyond the scope of volunteer developers; it would require professional developers with a professional development budget. -- Doug Ewell * Thornton, Colorado, USA * RFC 4645 * UTN #14 http://www.ewellic.org http://www1.ietf.org/html.charters/ltru-charter.html http://www.alvestrand.no/mailman/listinfo/ietf-languages ˆ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 3 jul 2009, at 0:35, Pete Resnick wrote: A much better solution would be HTML, if it's sufficiently constrained. Or, gee, we could generalize to a very constrained XML format XML isn't a display format. As Dave put it, the current RFC format is unfriendly, unnecessary, possibly unethical and just plain wrong. I'd remove the possibly. Please elaborate; this statement goes far beyond the inconvenience of having fixed line and page breaks and the lack of non-7-bit-ASCII characters. I wonder what people think about the need (or lack of need) to have graphical images. Having written a book or two, I can tell you that getting text right is hard, but this pales in comparison to the difficulty of getting images right. Most people, including myself, don't have the skills to create decent artwork. The formats are infinitely less open (in a variety of senses), so modifying someone else's images is extremely difficult unless you happen to use the same tools or go to the lowest common denominator = bitmaps. And images are of course impossible to use on text-only terminals. On constrained devices they're hard to work with because the text doesn't scale. So I think a good argument could be made that in general, RFCs shouldn't have images. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 3 jul 2009, at 13:13, Stewart Bryant wrote: That is an author centric view. It is far more important to take a reader centric view. Do we have any objective information on what format produced the clearest information transfer in the reader. Well, readers can't read what authors can't produce. Perhaps a good image trumps good text, but I don't think we can assume that this is the choice we'll be faced with in general, mediocre image vs good text or bad image vs mediocre text seems more likely. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC archival format, was: Re: More liberal draft formatting standards required
On 2 jul 2009, at 10:47, Yaakov Stein wrote: Due to his diminished eyesight he can't handle the text of the document he is co-authoring without significant preprocessing. Ok if we're going to have this discussion again: PDF is a way to display documents on the screen the same way that would appear on paper. Since screen and paper have different limitations, that usually entails pretty significant compromises. It's also extremely hard to build home grown tools to scrape PDF files. Even copy/paste from PDF is a challenge. So making PDF the authoritative version (let alone the only version) we create more problems than we solve. Exit PDF. A much better solution would be HTML, if it's sufficiently constrained. HTML allows for the reflowing of text, solving issues with text and screen sizes. It's also extremely widely implemented, so it's easy to display reasonably well without special tools. It also allows for semantic tagging, allowing for easy scraping. Last but not least, just filter out anything between and and replace a few xxx; sequences and you're back to plain text. We could probably even format RFCs such that if you remove the HTML, you're left with the current ASCII format. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: RFC archival format, was: Re: More liberal draft formatting standards required
On 2 jul 2009, at 17:05, Stewart Bryant wrote: A much better solution would be HTML This seems obviously true everywhere outside the IETF mailing list. The showstopper has always been with figures which need to do in separate files. How do you manipulate the collection of files as a single object? Multiple files seems problematic. However, we can stick with ASCII art even if we adopt HTML. ┏ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━━━┯━━━┓ ┃ An influx of a (hopefully limited) set │ of unicode symbols┃ ┃ could allow for more expressiveness in │ this area.┃ ┗ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━━━┷━━━┛___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
