Re: Getting to Quebec City
On Fri, Jun 17, 2011 at 5:32 PM, Eric Rescorla e...@rtfm.com wrote: On Fri, Jun 17, 2011 at 5:08 PM, John Levine jo...@iecc.com wrote: As you may have noticed, flying to Quebec City (YQB) is incredibly expensive. That's because it's a regional airport with little competion. Flying to Montreal is usuallly a lot cheaper. Getting from Trudeau airport in Montreal involves some planning, but it's not hard. The trip is about four hours; Quebec is big, bigger than any state in the US. Nitpick alert: http://en.wikipedia.org/wiki/Quebec http://en.wikipedia.org/wiki/List_of_U.S._states_and_territories_by_area Quebec: Land area=1,365,128 km2 Water Area=176,928 km2 Alaska: Land Area: 1,481,347 km2 Water Area=236,507 km2 Perhaps you meant Continental US. ...or Contiguous US, to rule out any misunderstanding :) http://en.wikipedia.org/wiki/Contiguous_United_States --julien ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Found Safeword Platinum tokencard
Folks, I found a Safeword Platinum tokencard on a lunch table on first floor above terminal room. I will hand it to the registration desk after this session finishes so you can pick it up from there c.a. 15:00. --julien ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Ream-Specific IP (Was: IPv4)
On Friday 03 August 2007, Keith Moore wrote: NAT isn't the only answer to the question I can't get IPv4 addresses, what do I do? Using IPv6 and a proxy to reach the IPv4 world is much, much cleaner. And it also works from v4 to v6. We really should start advocating this as the preferred transition mechanism. NAT and proxies are not mutually exclusive. There are advantages to having a proxy that can forward TCP and UDP traffic from an outside address/port to an inside address/port and vice versa; there are also advantages to a NAT that can do the same thing on a per-packet level. But a good, explicit protocol and API for doing each would be welcome. It would also be useful if the forwarder/NAT had explicit means of communicating the external source and destination address/port to the internal host - say via the same control protocol used to establish and maintain the address binding. FWIW, there's a protocol that would give you the same functionality as a NAT while preserving end-to-end transparency of the network (i.e. IPv4 packets won't be modified between the internal host on the IPv6-only network and its IPv4 correspondent outside in the IPv4 Internet). It would also let the internal host to know what address/port pair it was using to communicate, without change to the application. That's Ream-Specific IP [RFC3102][RFC3103]. That would make it relatively easy to, say, have a server inside an IPv6-only network establish presence on an IPv4 network provided by an ISP, while still allowing the application to see the real IPv4 source address (say for logging or spam filtering). Yes, that was pretty easy on an RSIP-enabled server on an IPv6-only network connected to the IPv4 world via an RSIP gateway, e.g. /etc/init.d/inetd start on the server! Last but not least, provided that an IKE implementation would be modified to work hand-in-hand [RC3104] with RSIP, it would also be possible to support end-to-end IPv4 IPsec while one or both ends are on an IPv6 only network. --julien [RFC3102] Realm Specific IP: Framework [RFC3103] Realm Specific IP: Protocol Specification [RFC3104] RSIP Support for End-to-end IPsec ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Fwd: Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC
[ I'm forwarding Samita's answer to ietf@ietf.org on her behalf. ] -- Forwarded Message -- Subject: Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC Date: Tuesday 05 June 2007 20:44 From: Samita Chakrabarti [EMAIL PROTECTED] To: Narayanan, Vidya [EMAIL PROTECTED] Cc: ietf@ietf.org, [EMAIL PROTECTED], Julien Laganier [EMAIL PROTECTED] Hi Vidya, The following comment has been addressed already as part of Ted Hardie's comments. A new API will be provided to select/bind the preferred source address before connect(). Thanks, -Samita On 6/4/07, Narayanan, Vidya [EMAIL PROTECTED] wrote: All, I'm passing along a comment from one of our developers. Sorry, I have not closely read the draft myself. But, if more clarification is needed, I'll be happy to get more information. In section 13, the draft describes a procedure applications should follow in case they require to use the address according to the selection preferences specified (they should not communicate with 'wrong' address and fail). The procedure requires the application to do a 'connect()' in step 3. The application may not even want to connect (may be a TCP application) in case it is not getting a non-preferred address. There should be a procedure described for such applications too. Thanks, Vidya -Original Message- From: The IESG [mailto:[EMAIL PROTECTED] Sent: Monday, May 07, 2007 3:41 PM To: IETF-Announce Subject: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC The IESG has received a request from an individual submitter to consider the following document: - 'IPv6 Socket API for Address Selection ' draft-chakrabarti-ipv6-addrselect-api-05.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2007-06-04. Exceptionally, comments may be sent to [EMAIL PROTECTED] instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-chakraba rti-ipv6-add rselect-api-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi ?command=vie w_iddTag=9992rfc_flag=0 ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announ ce --- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-chakrabarti-ipv6-addrselect-api (IPv6 Socket API for Address Selection) to Informational RFC
Hi Suresh, please see below: On Tuesday 05 June 2007 23:37, Suresh Krishnan wrote: Hi Vidya, (Cc:ing Julien as well) Narayanan, Vidya wrote: All, I'm passing along a comment from one of our developers. Sorry, I have not closely read the draft myself. But, if more clarification is needed, I'll be happy to get more information. In section 13, the draft describes a procedure applications should follow in case they require to use the address according to the selection preferences specified (they should not communicate with 'wrong' address and fail). The procedure requires the application to do a 'connect()' in step 3. The application may not even want to connect (may be a TCP application) in case it is not getting a non-preferred address. There should be a procedure described for such applications too. From what I understood from the draft, the API is used for specifying only preferences and not hard requirements. This text from Section 1 of the draft explains the reasoning. Specifying hard requirements for address selection would be problematic for several reasons. The major one is that in the vast majority of cases the application would like to be able to communicate even if an address with the 'optimal' attributes is not available. The authors can correct me, but I personally don't see how it is possible to check this deterministically without actually using connect() or sendto(). For argument's sake let's assume such a solution exists and the application verifies that a preferred address exists. What is to say this preferred address will not vanish before it is actually used (connect or sendto)? As part of discussion with IESG, we decided to take care of such TCP applications by defining a new bind function which binds a socket to the source address that would get selected to communicate with a given destination address, according to the preferences expressed by the application: int addrselectbind(int s, struct sockaddr *saddr, const struct sockaddr *daddr, socklen_t addrlen, int flag pref); It is called by passing as argument the socket, a memory location so that addrselectbind() can store the source address to which the socket is going to be bound, the destination address and the application preferences so that address selection algorithm can happens. On return, the application can use the validation function on the returned source address to make sure the address that got selected fullfills its requirements, and prior to sending any data with sendto() or connect(): short inet6_is_srcaddr(struct sockaddr_in6 *srcaddr, uint32_t flags); In case the address vanish before it is used, I think this is orthogonal to specification of this API: It is already possible with the usual socket API that an application binds to an address, then that same address gets unconfigured before the application eventually connect() or sendto(). Presumably the connect() call will fail with EADDRNOTAVAIL (i.e. the specified address is not available on this machine), and I'm not so sure if sendto() will fail and what errno would be appropriate: FreeBSD's sendto() manpage doesn't mention EADDRNOTAVAIL, only EHOSTUNREACH... Best, --julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: ID Tracker State Update Notice: draft-laganier-ipv6-khi
- Ceci est une réponse automatique - suite à votre message envoyé à [EMAIL PROTECTED] I'll be back on Monday, August 27th; I don't think I'll have connectivity before then. --julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: New Version Notification - draft-laganier-ipv6-khi-04.txt
- Ceci est une réponse automatique - suite à votre message envoyé à [EMAIL PROTECTED] I'll be back on Monday, August 27th; I don't think I'll have connectivity before then. --julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Hi Jordi, On Friday 24 March 2006 06:10, JORDI PALET MARTINEZ wrote: Not really. If you look to the recent sponsors, the current one and the next one, they are all European companies, hosting IETF in North America. Actually it can be presented in the other way around, as they host here, 50% of the attendees are getting indirectly subsidized by those sponsors decision to host here because their travel expenses are lower. So the cost for the participants from the rest of the world is higher. I do not agree that the cost for rest of the world participants is necessarily higher when me meet in US. It is usually cheaper for me to travel from EU to US than to travel from EU to EU. For example I paid 350 euros and 460 euros to go from France to Washington DC and San Francisco, respectively. That's more or less the minimum I am used to pay for intra-EU trips. So it rather seems that the cost of intercontinental flights is low when there is a lot of different carriers (competition!) on the hub-to-hub intercontinental trunk of the trip. My two cents. -- julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Making IETF happening in different regions
Jordi, You are speaking about low cost flights. I am sure they are readily available from/to any capital like Madrid, but what about other places. When I want to go from a secondary french city to a secondary city in germany without over the week-end stay (say monday-thursday) the prices can start at 500 euros or more, even if booked three months in advance. What I tried to say is that w.r.t. price, the continent location seems to matter more or less the same than the number of airlines going there. A major city with lot of connecting flights (Minneapolis ;) is much more cheaper to flight to than a secondary city. You seems to agree since you mentioned below European flights between European capitals. --julien On Wednesday 29 March 2006 14:49, JORDI PALET MARTINEZ wrote: Hi Julien, I guess is a question of planning. I tend to book my flights at least 3 months ahead. Then a flight Madrid-Europe-Madrid, for example, could be so law as 80 Euros (replace Europe with Munich, London, Paris, Brussels, or any other preferred EU destination). For the same period (a week, including Saturday night), Madrid-Dallas-Madrid is about 550 Euros. This typically works also just purchasing 5-6 weeks ahead of the flight departure. Regards, Jordi De: Julien Laganier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Wed, 29 Mar 2006 14:13:40 +0200 Para: ietf@ietf.org ietf@ietf.org, [EMAIL PROTECTED] Asunto: Re: Making IETF happening in different regions Hi Jordi, On Friday 24 March 2006 06:10, JORDI PALET MARTINEZ wrote: Not really. If you look to the recent sponsors, the current one and the next one, they are all European companies, hosting IETF in North America. Actually it can be presented in the other way around, as they host here, 50% of the attendees are getting indirectly subsidized by those sponsors decision to host here because their travel expenses are lower. So the cost for the participants from the rest of the world is higher. I do not agree that the cost for rest of the world participants is necessarily higher when me meet in US. It is usually cheaper for me to travel from EU to US than to travel from EU to EU. For example I paid 350 euros and 460 euros to go from France to Washington DC and San Francisco, respectively. That's more or less the minimum I am used to pay for intra-EU trips. So it rather seems that the cost of intercontinental flights is low when there is a lot of different carriers (competition!) on the hub-to-hub intercontinental trunk of the trip. My two cents. -- julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- julien -- julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: MARID back from the grave?
Hi Spencer, On Thursday 24 February 2005 13:15, Spencer Dawkins wrote: Maybe we could improve the announcements to say what the WG (WGs?) are for a draft, and we could quit twisting in this self-inflicted wind? But isn't it already the case? Quoting I-D announce: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the XXX Working Group of the IETF Thanks, --julien ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
