Re: Has anyone found a hotel for Quebec City that isn't exorbitant?
On 6/21/2011 11:30 AM, Joel Jaeggli wrote: ... Actually, it seems that the conference rates at IETF hotels are quite predictable: a couple of months ago it was possible to book a room at the QC Hilton for $176 CAD/night _during the IETF meeting_; if you check the Hilton Web site right now, you will find that equivalent rooms at the Hilton the week before the IETF run about $100 less than during the meeting. It's possible that IETF week marks the transition to high season rates, but in that case why not move the meeting by a week? This is not an isolated case: in Beijing, rooms at the Shangri-La were significantly cheaper both the week before and the week after the IETF; in Hiroshima, I got a room at the conference hotel the week of the meeting for ~$50/night less than the conference rate by eschewing free breakfast. Admittedly the breakfast in Hiroshima was both tasty and plentiful, but $50? Not even in Japan. It seems apparent that the IAOC negotiators are wearing signs around their necks during the hotel negotiations; the only question is what is written on the signs. Is it I am a moron or the simple but effective F*k Me It has been repeated ad-nausieum that conference rates subsidize the rental of the meeting room block... So you believe that that is a good way to negotiate? That could explain a lot by itself... The fact that the conference rates are more expensive ( on a contract signed 24 months out) than a spot check of the room rate at any given time should come as no surprise to anyone. Really? So I should expect to pay less as an individual renting a room than as a member of a group renting 200? In what universe does that make sense? You can cruise the IETF finances if for some reason you don't believe this. If the room block doesn't get filled you can expect your fees to go up accordingly over time. IEEE 802 had that problem; the last time I checked, their solution was to raise the meeting fee ($1000 at the recent meeting in Singapore, for example, without early-bird discounts) and discount it if one could prove that they spent at least 1 night in the conference hotel. Of course, their excuse was a corrupt meeting arranger who locked them into exorbitant prices years in advance I will observe that I have generally not paid the conference rate or stayed in the meeting hotel while attending the IETF on my own dime (and have stayed in some rather nicer hotels (paris, stockholm, etc) for less money as a result. When I attend on behalf my employer I make it clear what we paying for when participating. please look at the balance sheet here: http://iaoc.ietf.org/documents/Meeting-Financials-2010-77.pdf and note both the hotel commission, a credit, and the zero charge associated with meeting rooms. It's not clear to me that this can be made more transparent, but if you'd like to try I'm sure that someone would be happy to nominate you for an open iaoc position when available. Thanks for the non-answer. My comment had nothing to do with transparency, however, and everything to do with competence...I do wonder what the difference is to us if we pay for the meeting rooms directly (through meeting fees) or indirectly (through increased room rates)? joel attachment: gwz.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Has anyone found a hotel for Quebec City that isn't exorbitant?
On Jun 21, 2011, at 1:31 AM, Thomas Heide Clausen wrote: On Jun 21, 2011, at 06:30 , Joel Jaeggli wrote: It has been repeated ad-nausieum that conference rates subsidize the rental of the meeting room block... The fact that the conference rates are more expensive ( on a contract signed 24 months out) than a spot check of the room rate at any given time should come as no surprise to anyone. You can cruise the IETF finances if for some reason you don't believe this. If the room block doesn't get filled you can expect your fees to go up accordingly over time. I will observe that I have generally not paid the conference rate or stayed in the meeting hotel while attending the IETF on my own dime (and have stayed in some rather nicer hotels (paris, stockholm, etc) for less money as a result. When I attend on behalf my employer I make it clear what we paying for when participating. Just one additional data-point here. For some of us, getting reimbursed for a higher meeting fee is actually a lot easier than getting reimbursed for a higher hotel-fee. Such would be the case when, for example, traveling on a fixed per-diem intended for covering accommodation/food, but reimbursed on cost for the meeting fee. Then again, for others of us, staying at a cheaper hotel a short distance away is actually a lot easier than paying out the wazoo for an overpriced meeting venue. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Has anyone found a hotel for Quebec City that isn't exorbitant?
On Jun 20, 2011, at 11:16 PM, Glen Zorn wrote: On 6/21/2011 11:30 AM, Joel Jaeggli wrote: ... Actually, it seems that the conference rates at IETF hotels are quite predictable: a couple of months ago it was possible to book a room at the QC Hilton for $176 CAD/night _during the IETF meeting_; if you check the Hilton Web site right now, you will find that equivalent rooms at the Hilton the week before the IETF run about $100 less than during the meeting. It's possible that IETF week marks the transition to high season rates, but in that case why not move the meeting by a week? This is not an isolated case: in Beijing, rooms at the Shangri-La were significantly cheaper both the week before and the week after the IETF; in Hiroshima, I got a room at the conference hotel the week of the meeting for ~$50/night less than the conference rate by eschewing free breakfast. Admittedly the breakfast in Hiroshima was both tasty and plentiful, but $50? Not even in Japan. It seems apparent that the IAOC negotiators are wearing signs around their necks during the hotel negotiations; the only question is what is written on the signs. Is it I am a moron or the simple but effective F*k Me It has been repeated ad-nausieum that conference rates subsidize the rental of the meeting room block... So you believe that that is a good way to negotiate? That could explain a lot by itself... nope, factual reporting should not be construed as approval. The fact that the conference rates are more expensive ( on a contract signed 24 months out) than a spot check of the room rate at any given time should come as no surprise to anyone. Really? So I should expect to pay less as an individual renting a room than as a member of a group renting 200? In what universe does that make sense? In the universe where you sign a contract with a hotel for use of their facilities two years you are in effect paying a risk premium since you a enjoining them from selling the facility out from under you. If you've ever entered into a futures contract you might be familiar with this... The customer who soaks up unused capacity 3 weeks out will pay less for the privledge they may not be able to book a meeting room however... The feedback that I provided into the IASA when the management of the activity moved from CNRI to the IAOC/IAD was that more flexibility on dates made it easier to negotiate with hotels on both fees and the use of facilities. The IETF community indicated unequically that meeting dates be known as far in advance as feasible, and in particular, the dates are fixed considerably ahead of hotel contracts, this does not increase your flexibility in negioating. You can cruise the IETF finances if for some reason you don't believe this. If the room block doesn't get filled you can expect your fees to go up accordingly over time. IEEE 802 had that problem; the last time I checked, their solution was to raise the meeting fee ($1000 at the recent meeting in Singapore, for example, without early-bird discounts) and discount it if one could prove that they spent at least 1 night in the conference hotel. Of course, their excuse was a corrupt meeting arranger who locked them into exorbitant prices years in advance I will observe that I have generally not paid the conference rate or stayed in the meeting hotel while attending the IETF on my own dime (and have stayed in some rather nicer hotels (paris, stockholm, etc) for less money as a result. When I attend on behalf my employer I make it clear what we paying for when participating. please look at the balance sheet here: http://iaoc.ietf.org/documents/Meeting-Financials-2010-77.pdf and note both the hotel commission, a credit, and the zero charge associated with meeting rooms. It's not clear to me that this can be made more transparent, but if you'd like to try I'm sure that someone would be happy to nominate you for an open iaoc position when available. Thanks for the non-answer. My comment had nothing to do with transparency, however, and everything to do with competence... Which you are qualified to asses on the basis of you long experience in meeting booking... I do wonder what the difference is to us if we pay for the meeting rooms directly (through meeting fees) or indirectly (through increased room rates)? joel gwz.vcf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Has anyone found a hotel for Quebec City that isn't exorbitant?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/21/2011 1:16 PM, Glen Zorn wrote: ... please look at the balance sheet here: http://iaoc.ietf.org/documents/Meeting-Financials-2010-77.pdf and note both the hotel commission, a credit, and the zero charge associated with meeting rooms. It's not clear to me that this can be made more transparent, but if you'd like to try I'm sure that someone would be happy to nominate you for an open iaoc position when available. Thanks for the non-answer. It seems that your response was even less responsive than I had thought: according to the meeting Web site, the meeting is actually to be held at the Quebec City Convention Center. This makes it rather unsurprising that there is a zero charge associated with meeting rooms at the Hilton but begs the question: what, exactly, _is_ being subsidized by the extra ~$70/night? ... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOAEGRAAoJEG4XtfZZU7RfVqEH/iUlVjbkKhxRnROzTNZjre69 eNfCpMIeK745Mvme0RyhO+ycApo+x4aWEi36mNB8p1IyIpjLZz65LgBY2TGI7tQN 6Mmv38FYDoJnruEIpjmuuvuAZQyMVzanDHINCsAAk20ytD7zgUPwtCfk91R6gOVW XnIQxlDBZcHLj+t12PBB8UuXuQ+VyxIaBZWxsM59G5s8uFlMoSgjOomU/vI8lVJR ouXcUdc5HSPwUITrU+XbfWQxrck3QJoC6WfNAYhkVpEBhxrgcm33uVZOwMH/PKY3 t1A7VErp4u8+QjphPfEy9XEhP08pYQaGufW3vpTmhyXSkXnOSzr2fK6ssbnQpNc= =aCK6 -END PGP SIGNATURE- attachment: gwz.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Has anyone found a hotel for Quebec City that isn't exorbitant?
On 6/21/2011 1:48 PM, Joel Jaeggli wrote: ... Which you are qualified to asses on the basis of you long experience in meeting booking... As a matter of fact, yes. ... attachment: gwz.vcf___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Has anyone found a hotel for Quebec City that isn't exorbitant?
On Jun 21, 2011, at 12:00 AM, Glen Zorn wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/21/2011 1:16 PM, Glen Zorn wrote: ... please look at the balance sheet here: http://iaoc.ietf.org/documents/Meeting-Financials-2010-77.pdf and note both the hotel commission, a credit, and the zero charge associated with meeting rooms. It's not clear to me that this can be made more transparent, but if you'd like to try I'm sure that someone would be happy to nominate you for an open iaoc position when available. Thanks for the non-answer. It seems that your response was even less responsive than I had thought: according to the meeting Web site, the meeting is actually to be held at the Quebec City Convention Center. This makes it rather unsurprising that there is a zero charge associated with meeting rooms at the Hilton but begs the question: what, exactly, _is_ being subsidized by the extra ~$70/night? I'll see the financials the same as everyone else, when they are published... it wouldn't shock me if they were similar to another canadian city owned meeting venue which we visited in 2006 which of course you can see here: http://iaoc.ietf.org/documents/IETF66_Montreal_Financial_Statement.pdf inclusive of the unbudgeted $2,475 in meeting room expenses. City owned conference facilties are part and parcel of the fee structure of the associated businesses. ... -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOAEGRAAoJEG4XtfZZU7RfVqEH/iUlVjbkKhxRnROzTNZjre69 eNfCpMIeK745Mvme0RyhO+ycApo+x4aWEi36mNB8p1IyIpjLZz65LgBY2TGI7tQN 6Mmv38FYDoJnruEIpjmuuvuAZQyMVzanDHINCsAAk20ytD7zgUPwtCfk91R6gOVW XnIQxlDBZcHLj+t12PBB8UuXuQ+VyxIaBZWxsM59G5s8uFlMoSgjOomU/vI8lVJR ouXcUdc5HSPwUITrU+XbfWQxrck3QJoC6WfNAYhkVpEBhxrgcm33uVZOwMH/PKY3 t1A7VErp4u8+QjphPfEy9XEhP08pYQaGufW3vpTmhyXSkXnOSzr2fK6ssbnQpNc= =aCK6 -END PGP SIGNATURE- gwz.vcf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: location preferences
On Jun 20, 2011, at 5:24 PM, James M. Polk wrote: rumor has it that IETF65 was supposed to be in New Orleans that November, but got hit by a little event called Katrina, so (again - only rumors) there had to be a mad scramble to find any hotel that could take 1400 in 2 months notice. Don't hold Dallas being hit by a freak storm against the city's ability to have a decent conference - especially given more time to plan which hotel to stay in. Fortunately, Dallas has a few other choices that are likely to work better, along every parameter we care about. yes it does James Having surveyed three of the downtown dallas venues suitable for a meeting the size of the ietf including the one where we did IETF 34 and done another meeting in a 4th, there is some horrible network plant in several of them among other things. So like all venues there's not a unequivocal slam-dunk. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Has anyone found a hotel for Quebec City that isn't exorbitant?
I agree with Thomas, the meeting fees should cover the meetings and the hotel bill should cover only an individual's room. This would be more transparent! Please feel free to take this as criticism (of the current fee distribution policy). Lou On 6/21/2011 1:31 AM, Thomas Heide Clausen wrote: On Jun 21, 2011, at 06:30 , Joel Jaeggli wrote: It has been repeated ad-nausieum that conference rates subsidize the rental of the meeting room block... The fact that the conference rates are more expensive ( on a contract signed 24 months out) than a spot check of the room rate at any given time should come as no surprise to anyone. You can cruise the IETF finances if for some reason you don't believe this. If the room block doesn't get filled you can expect your fees to go up accordingly over time. I will observe that I have generally not paid the conference rate or stayed in the meeting hotel while attending the IETF on my own dime (and have stayed in some rather nicer hotels (paris, stockholm, etc) for less money as a result. When I attend on behalf my employer I make it clear what we paying for when participating. Just one additional data-point here. For some of us, getting reimbursed for a higher meeting fee is actually a lot easier than getting reimbursed for a higher hotel-fee. Such would be the case when, for example, traveling on a fixed per-diem intended for covering accommodation/food, but reimbursed on cost for the meeting fee. For me, not an eyelid would be bat if I presented a quadruple (or more) meeting-fee-bill -- whereas it is a recurring administrative hassle to actually get a hotel-bill exceeding the per-diem to pass accounting (and, actually quite a lottery each time if it will be reimbursed) Not wanting to criticize, but I would encourage that such situations also be considered when making plans for the IETF meeting payment structure. Sincerely yours Thomas ps: Other than that, I am actually excited to go to Quebec City which - for those who've never been there - is a very very pleasant place to be. Also, when there, my French colleagues tend to mock me a whole lot less for my accent ;) please look at the balance sheet here: http://iaoc.ietf.org/documents/Meeting-Financials-2010-77.pdf and note both the hotel commission, a credit, and the zero charge associated with meeting rooms. It's not clear to me that this can be made more transparent, but if you'd like to try I'm sure that someone would be happy to nominate you for an open iaoc position when available. joel ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Has anyone found a hotel for Quebec City that isn't exorbitant?
+1 And aware this might mean a sizeable hike in meeting fees. The *only* wrinkle I can see is that it might be considered useful for a hotel to block out a number of rooms for booking exclusively by IETF participants, and the hotel might want to increase the price for that service (because it is a risk for them that they will not sell all the rooms). The counterpart to this is that we might have to take whatever rooms are available in nearby hotels if the IETF hotel sells out. But we have to go down this path anyway. An increasing number of IETF participants are booking their rooms independently, either in the IETF hotels or in nearby hotels. The result of this would appear to be the distribution of the meeting room costs across a smaller number of guest rooms leading to still higher guest room prices. Loop until done. Adrian -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Lou Berger Sent: 21 June 2011 12:48 To: Thomas Heide Clausen; Joel Jaeggli Cc: Henk Uijterwaal; Ole Jacobsen; ietf@ietf.org; Keith Moore Subject: Re: Has anyone found a hotel for Quebec City that isn't exorbitant? I agree with Thomas, the meeting fees should cover the meetings and the hotel bill should cover only an individual's room. This would be more transparent! Please feel free to take this as criticism (of the current fee distribution policy). Lou On 6/21/2011 1:31 AM, Thomas Heide Clausen wrote: On Jun 21, 2011, at 06:30 , Joel Jaeggli wrote: It has been repeated ad-nausieum that conference rates subsidize the rental of the meeting room block... The fact that the conference rates are more expensive ( on a contract signed 24 months out) than a spot check of the room rate at any given time should come as no surprise to anyone. You can cruise the IETF finances if for some reason you don't believe this. If the room block doesn't get filled you can expect your fees to go up accordingly over time. I will observe that I have generally not paid the conference rate or stayed in the meeting hotel while attending the IETF on my own dime (and have stayed in some rather nicer hotels (paris, stockholm, etc) for less money as a result. When I attend on behalf my employer I make it clear what we paying for when participating. Just one additional data-point here. For some of us, getting reimbursed for a higher meeting fee is actually a lot easier than getting reimbursed for a higher hotel-fee. Such would be the case when, for example, traveling on a fixed per-diem intended for covering accommodation/food, but reimbursed on cost for the meeting fee. For me, not an eyelid would be bat if I presented a quadruple (or more) meeting-fee-bill -- whereas it is a recurring administrative hassle to actually get a hotel-bill exceeding the per-diem to pass accounting (and, actually quite a lottery each time if it will be reimbursed) Not wanting to criticize, but I would encourage that such situations also be considered when making plans for the IETF meeting payment structure. Sincerely yours Thomas ps: Other than that, I am actually excited to go to Quebec City which - for those who've never been there - is a very very pleasant place to be. Also, when there, my French colleagues tend to mock me a whole lot less for my accent ;) please look at the balance sheet here: http://iaoc.ietf.org/documents/Meeting-Financials-2010-77.pdf and note both the hotel commission, a credit, and the zero charge associated with meeting rooms. It's not clear to me that this can be made more transparent, but if you'd like to try I'm sure that someone would be happy to nominate you for an open iaoc position when available. joel ___ 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 ___ 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: whine, whine, whine
On 2011-06-20 23:52, John Levine wrote: * There is no usable bus from the airport (it runs only at commuter hours) and a taxi costs C$32.50 You're absolutely right about this. The people of Québec are not happy about this situation and often complain in the media. It makes for a bad first impression. We'll try to organize taxi pools somehow, stay tuned and read 81attend...@ietf.org. Assuming the others bullets were jokes... ;) Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
On 2011-06-21 01:06, Randall Gellens wrote: San Diego is much easier to get to than Quebec City, since multiple air carriers serve it. Not going to argue about San Diego vs Québec, but just going to point out that multiple carriers do serve Québec. Among them are Air Canada, United, Continental, Delta, and US Airways. See http://ietf81.ca/?page_id=10 Simon -- DTN made easy, lean, and smart -- http://postellation.viagenie.ca NAT64/DNS64 open-source-- http://ecdysis.viagenie.ca STUN/TURN server -- http://numb.viagenie.ca ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: whine, whine, whine
* There is no usable bus from the airport (it runs only at commuter hours) and a taxi costs C$32.50 You're absolutely right about this. The people of Québec are not happy about this situation and often complain in the media. It makes for a bad first impression. We'll try to organize taxi pools somehow, stay tuned and read 81attend...@ietf.org. Assuming the others bullets were jokes... ;) One could wish so, but you obviously haven't seen what kind of things people use to whine about when it comes to IETF meetings... :) Regards, Christer ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
On 21 Jun 2011, at 14:02, Simon Perreault wrote: Not going to argue about San Diego vs Québec, but just going to point out that multiple carriers do serve Québec. Among them are Air Canada, United, Continental, Delta, and US Airways. The only European operator into YBQ appears to be Air Transat (whoever the heck they are) and they only fly from Marseille and Paris. I'm flying BA to Montreal and taking the short city hopper flight to YBQ from there. Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
Le 21/06/2011 15:28, Ray Bellis a écrit : On 21 Jun 2011, at 14:02, Simon Perreault wrote: Not going to argue about San Diego vs Québec, but just going to point out that multiple carriers do serve Québec. Among them are Air Canada, United, Continental, Delta, and US Airways. The only European operator into YBQ appears to be Air Transat (whoever the heck they are) and they only fly from Marseille and Paris. Wikipedia says Air Transat is a Canadian company. http://en.wikipedia.org/wiki/Air_Transat I'm flying BA to Montreal and taking the short city hopper flight to YBQ from there. Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
On 21 Jun 2011, at 14:28, Ray Bellis wrote: On 21 Jun 2011, at 14:02, Simon Perreault wrote: Not going to argue about San Diego vs Québec, but just going to point out that multiple carriers do serve Québec. Among them are Air Canada, United, Continental, Delta, and US Airways. The only European operator into YBQ appears to be Air Transat (whoever the heck they are) and they only fly from Marseille and Paris. I'm flying BA to Montreal and taking the short city hopper flight to YBQ from there. For a single operator trip from the UK to Quebec City, there's Air Canada out of Heathrow. You can go via Montreal or other cities. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
The only European operator into YQB appears to be Air Transat (whoever the heck they are) and they only fly from Marseille and Paris. Air Transat is a Montreal-based quasi-charter carrier that specialize in holiday travel. Their A330s have kneecap killing 31 seat pitch so I would only fly them if I had a premium seat or at least a guaranteed exit row. But their fares are often quite cheap. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
On 21 Jun 2011, at 14:37, Tim Chown wrote: For a single operator trip from the UK to Quebec City, there's Air Canada out of Heathrow. You can go via Montreal or other cities. I seem to recall that it was actually somewhat cheaper to fly BA. Although I didn't check economy class... Ray ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
On 6/21/11 7:20 AM, John R. Levine wrote: San Diego is much easier to get to than Quebec City, since multiple air carriers serve it. You can't fool me. I've been to both. Quebec is a lot closer, and the food is better. Hey! Then you haven't been to DZ Akins! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: location preferences
Folks, Having surveyed three of the downtown dallas venues suitable for a meeting the size of the ietf including the one where we did IETF 34 and done another meeting in a 4th, there is some horrible network plant in several of them among other things. So like all venues there's not a unequivocal slam-dunk. As long as the IETF community prefers to travel to new venues, each meeting will run the risk of the unknown and the effort to adapt to it. We will not get any of the benefit of a learning curve that accrues from re-visiting venues. As for Vancouver vs. Quebec City, note that there was a survey. I believe that respondents stated a roughly 2:1 preference for Quebec City, primarily along the lines of liking that it was a new place. In effect, that said that tourism is a high priority for IETF attendees. There is a disconnect between attendees' desire for easy and inexpensive travel and convenient IETF work environments, versus the desire for interesting venues. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/21/11 3:28 PM, Ray Bellis wrote: On 21 Jun 2011, at 14:02, Simon Perreault wrote: Not going to argue about San Diego vs Québec, but just going to point out that multiple carriers do serve Québec. Among them are Air Canada, United, Continental, Delta, and US Airways. The only European operator into YBQ appears to be Air Transat (whoever the heck they are) and they only fly from Marseille and Paris. I'm flying BA to Montreal and taking the short city hopper flight to YBQ from there. otoh, not having to go through US immigrations saves you about as much time as you would have saved with a direct flight, not to mention the terrorist until proven innocent treatment. ;-) Klaas -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.14 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4AoCYACgkQH2Wy/p4XeFIWogCfW2dn+A+anCx0NIILJ6SPAqLx J9IAn30Txe/eoIzxaF87lgf/sYKFkeG7 =zVIP -END PGP SIGNATURE- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Has anyone found a hotel for Quebec City that isn't exorbitant?
- Original Message - From: Mary Barnes mary.ietf.bar...@gmail.com To: John C Klensin john-i...@jck.com Cc: ietf@ietf.org Sent: Monday, June 20, 2011 9:02 PM Subject: Re: Has anyone found a hotel for Quebec City that isn't exorbitant? Exactly. Given that we spend most of our days in air conditioned meeting rooms, Phoenix or Dallas are not bad choices. Dallas is slightly better due to air connections. Houston is not a good choice under any circumstance IMHO - I don't think A/C can remove enough humidity to make it comfortable in July. Personally, I have no issue with Minneapolis in November or March - again we spend most of the time in meeting rooms, so do we really care that much about the weather outside? Only when it disrupts the football or the baseball:-) Tom Petch Mary. On Mon, Jun 20, 2011 at 1:55 PM, John C Klensin john-i...@jck.com wrote: --On Monday, June 20, 2011 13:32 -0400 Michael Richardson m...@sandelman.ca wrote: ... It's a peak season destination. We seem to do this a lot. March would be no better, but early November there would be, I think, low peak. What's a non-peak destination for July? Phoenix. Probably Houston or Fort Worth. Wellington or somewhere on the South Island that doesn't attract skiers. Amundsen-Scott base: although I doubt that they have adequate conference facilities, yesterday's mean temperature was circa -89F and daytime is still several months off. Other silly suggestions on request (although I don't personally consider some of the first few silly). john ___ 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 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
Earlier, Ray Bellis wrote: The only ... operator into YBQ appears to be Air Transat (whoever the heck they are) and they only fly from Marseille and Paris. I have been told that Air Transat lacks the many comforts, low fully-disclosed fees, and general friendliness of Ryan Air. I've never flown Air Transat, so perhaps those reports are exaggerated. Earlier, John Levine wrote: Their A330s have kneecap killing 31 seat pitch so I would only fly them if I had a premium seat or at least a guaranteed exit row. If one believes the information available online at SeatExpert.com or SeatGuru.com, a 31 seat pitch in ordinary Economy cabins is not unusual for an overseas flight on a wide range of airlines (e.g. AA, BA, KL, LH), depending upon aircraft type, by the way. Not all aircraft seats with a given pitch are equally comfortable. Also, many people opt for various forms of Premium Economy or select particular aircraft types/configurations -- precisely because they prefer more leg room. Earlier, Klaas Wierenga wrote: otoh, not having to go through US immigrations saves you about as much time as you would have saved with a direct flight, not to mention the terrorist until proven innocent treatment. ;-) I agree that minimising the set of security-checks and immigration-steps is desirable for most travel these days. [ For my own part, I share the weariness of the terrorist until proven innocent treatment -- that I routinely receive at Heathrow, Frankfurt, and a range of other airports (Singapore being a notable exception). :-] Cheers, Ran PS: Singapore would make a great future A/P region meeting venue. It has outstanding international air connectivity, a wide range of hotel options, outstanding (and affordable) food, consistently pleasant weather, and consistently friendly and helpful local people. :-) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: whine, whine, whine
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ray Bellis Sent: Tuesday, June 21, 2011 6:29 AM To: ietf@ietf.org Subject: Re: whine, whine, whine The only European operator into YBQ appears to be Air Transat (whoever the heck they are) and they only fly from Marseille and Paris. They're actually a lesser-known Canadian airline, based out of Montreal. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Has anyone found a hotel for Quebec City that isn't exorbitant?
From: Thomas Heide Clausen [i...@thomasclausen.org] For some of us, getting reimbursed for a higher meeting fee is actually a lot easier than getting reimbursed for a higher hotel-fee. Such would be the case when, for example, traveling on a fixed per-diem intended for covering accommodation/food, but reimbursed on cost for the meeting fee. A good point, but part of the reasoning for the current fee structure (subsidizing the meeting proper via the hotel rooms) is to make it possible to attend cheaply by locals and people on limited budgets who are willing to book inexpensive accommodations. From: John C Klensin [john-i...@jck.com] What's a non-peak destination for July? Phoenix. Probably Houston or Fort Worth. I think that rooms could be obtained cheaply in Maimi in July. (The typical daily high is around 34 C, with high humidity.) Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: whine, whine, whine
Ray, The only European operator into YBQ appears to be Air Transat (whoever the heck they are) and they only fly from Marseille and Paris. They are pretty famous, for running out of fuel over the Atlantic. (Luckily, everyone survived.) I'm flying BA to Montreal and taking the short city hopper flight to YBQ from there. I'm still wondering what route to take, the alliance that I use (OneWorld) does not serve Quebec City too well. Maybe I'll pick some two hop solution to a nearby city such as Montreal and then drive the rest of the way, or a three hop approach that involves Air Canada for the last leg. Apparently, Iceland Air could also deliver me to Quebec in three hops. In any case, looking very much forward to Quebec City! Jari ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
25 or 6to4
A bit of levity about migration to IPv6, with apologies to Robert Lamm and with thanks to Dan Wing and Joe Hildebrand... ### Waiting for the break of day (yes, the dawn will come with the universal deployment of IPv6) Searching for something to say (how will we communicate once IPv4 is gone?) Flashing lights against the sky (hoping for extraterrestrial intervention to solve the problem) Giving up I close my eyes (ignoring IPv4 address exhaustion) Staring blindly into space (have you ever read all the IPv6-related specifications in one sitting?) Getting up to splash my face (February 3, 2011 was a wakeup call, no?) Wanting just to stay awake (simply wishing for the Internet to keep working) Wondering how much I can take (these v4 to v6 discussions are interminable, aren't they?) Should I try to do some more? (pondering the idea of writing an Internet-Draft) 25 or 6to4 (yes, port 25 is the answer -- perhaps the problem will solve itself if we all just send more email to ietf@ietf.org!) ### smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 25 or 6to4
Wow. An absolute tour de force from someone who *clearly* has too much time on his hands. Thanks; made my day. Well, except for now I've got that long-forgotten tune stuck in my head... - Ralph On Jun 21, 2011, at 5:47 PM 6/21/11, Peter Saint-Andre wrote: A bit of levity about migration to IPv6, with apologies to Robert Lamm and with thanks to Dan Wing and Joe Hildebrand... ### Waiting for the break of day (yes, the dawn will come with the universal deployment of IPv6) Searching for something to say (how will we communicate once IPv4 is gone?) Flashing lights against the sky (hoping for extraterrestrial intervention to solve the problem) Giving up I close my eyes (ignoring IPv4 address exhaustion) Staring blindly into space (have you ever read all the IPv6-related specifications in one sitting?) Getting up to splash my face (February 3, 2011 was a wakeup call, no?) Wanting just to stay awake (simply wishing for the Internet to keep working) Wondering how much I can take (these v4 to v6 discussions are interminable, aren't they?) Should I try to do some more? (pondering the idea of writing an Internet-Draft) 25 or 6to4 (yes, port 25 is the answer -- perhaps the problem will solve itself if we all just send more email to ietf@ietf.org!) ### ___ 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: 25 or 6to4
I needed a diversion from reviewing draft-ietf-v6ops-6to4-to-historic and its associated IETF LC comments. Back to my IESG duties now... ;-) On 6/21/11 4:14 PM, Ralph Droms wrote: Wow. An absolute tour de force from someone who *clearly* has too much time on his hands. Thanks; made my day. Well, except for now I've got that long-forgotten tune stuck in my head... - Ralph On Jun 21, 2011, at 5:47 PM 6/21/11, Peter Saint-Andre wrote: A bit of levity about migration to IPv6, with apologies to Robert Lamm and with thanks to Dan Wing and Joe Hildebrand... ### Waiting for the break of day (yes, the dawn will come with the universal deployment of IPv6) Searching for something to say (how will we communicate once IPv4 is gone?) Flashing lights against the sky (hoping for extraterrestrial intervention to solve the problem) Giving up I close my eyes (ignoring IPv4 address exhaustion) Staring blindly into space (have you ever read all the IPv6-related specifications in one sitting?) Getting up to splash my face (February 3, 2011 was a wakeup call, no?) Wanting just to stay awake (simply wishing for the Internet to keep working) Wondering how much I can take (these v4 to v6 discussions are interminable, aren't they?) Should I try to do some more? (pondering the idea of writing an Internet-Draft) 25 or 6to4 (yes, port 25 is the answer -- perhaps the problem will solve itself if we all just send more email to ietf@ietf.org!) ### smime.p7s Description: S/MIME Cryptographic Signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 25 or 6to4
Now that I've swapped back in some more recollections - yes, I did see Chicago perform it live when it was first released - I'm glad you finally cleared up the meaning behind the lyrics. I always thought the lyrics somehow drug-related ... of course, we thought a lot of lyrics were drug-related then. More recently I thought it was about reading drafts for a telechat. - Ralph On Jun 21, 2011, at 6:18 PM 6/21/11, Peter Saint-Andre wrote: I needed a diversion from reviewing draft-ietf-v6ops-6to4-to-historic and its associated IETF LC comments. Back to my IESG duties now... ;-) On 6/21/11 4:14 PM, Ralph Droms wrote: Wow. An absolute tour de force from someone who *clearly* has too much time on his hands. Thanks; made my day. Well, except for now I've got that long-forgotten tune stuck in my head... - Ralph On Jun 21, 2011, at 5:47 PM 6/21/11, Peter Saint-Andre wrote: A bit of levity about migration to IPv6, with apologies to Robert Lamm and with thanks to Dan Wing and Joe Hildebrand... ### Waiting for the break of day (yes, the dawn will come with the universal deployment of IPv6) Searching for something to say (how will we communicate once IPv4 is gone?) Flashing lights against the sky (hoping for extraterrestrial intervention to solve the problem) Giving up I close my eyes (ignoring IPv4 address exhaustion) Staring blindly into space (have you ever read all the IPv6-related specifications in one sitting?) Getting up to splash my face (February 3, 2011 was a wakeup call, no?) Wanting just to stay awake (simply wishing for the Internet to keep working) Wondering how much I can take (these v4 to v6 discussions are interminable, aren't they?) Should I try to do some more? (pondering the idea of writing an Internet-Draft) 25 or 6to4 (yes, port 25 is the answer -- perhaps the problem will solve itself if we all just send more email to ietf@ietf.org!) ### ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 25 or 6to4
I did an interview for BBC Radio for New Year's Day several years ago about the early days of developing the Arpanet. The closing question was why, in 1968, we weren't at Woodstock. I replied, For us, computers were the drug of choice. Steve On Jun 22, 2011, at 6:46 AM, Ralph Droms wrote: Now that I've swapped back in some more recollections - yes, I did see Chicago perform it live when it was first released - I'm glad you finally cleared up the meaning behind the lyrics. I always thought the lyrics somehow drug-related ... of course, we thought a lot of lyrics were drug-related then. More recently I thought it was about reading drafts for a telechat. - Ralph On Jun 21, 2011, at 6:18 PM 6/21/11, Peter Saint-Andre wrote: I needed a diversion from reviewing draft-ietf-v6ops-6to4-to-historic and its associated IETF LC comments. Back to my IESG duties now... ;-) On 6/21/11 4:14 PM, Ralph Droms wrote: Wow. An absolute tour de force from someone who *clearly* has too much time on his hands. Thanks; made my day. Well, except for now I've got that long-forgotten tune stuck in my head... - Ralph On Jun 21, 2011, at 5:47 PM 6/21/11, Peter Saint-Andre wrote: A bit of levity about migration to IPv6, with apologies to Robert Lamm and with thanks to Dan Wing and Joe Hildebrand... ### Waiting for the break of day (yes, the dawn will come with the universal deployment of IPv6) Searching for something to say (how will we communicate once IPv4 is gone?) Flashing lights against the sky (hoping for extraterrestrial intervention to solve the problem) Giving up I close my eyes (ignoring IPv4 address exhaustion) Staring blindly into space (have you ever read all the IPv6-related specifications in one sitting?) Getting up to splash my face (February 3, 2011 was a wakeup call, no?) Wanting just to stay awake (simply wishing for the Internet to keep working) Wondering how much I can take (these v4 to v6 discussions are interminable, aren't they?) Should I try to do some more? (pondering the idea of writing an Internet-Draft) 25 or 6to4 (yes, port 25 is the answer -- perhaps the problem will solve itself if we all just send more email to ietf@ietf.org!) ### ___ 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: 25 or 6to4
I've been thinking of the protocol as 25 ever since Brian suggested the name 6to4 :) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-dkim-rfc4871bis-12.txt (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
Background on preceding DKIM work-- RFC4686 Introduction states: ,--- The DKIM protocol defines a mechanism by which email messages can be cryptographically signed, permitting a signing domain to claim responsibility for the use of a given email address. '--- While several threats to DKIM were considered, multiple From header fields were neglected. This document only focused on use of multiple addresses within the From header field. RFC5585 Introduction states: ,--- DKIM allows an organization to take responsibility for a message in a way that can be verified by a recipient. [..] It permits verification of the signer of a message, as well as the integrity of its contents. DKIM will also provide a mechanism that permits potential email signers to publish information about their email signing practices; this will permit email receivers to make additional assessments of unsigned messages. DKIM's authentication of email identity can assist in the global control of spam and phishing. '--- It should be noted that Signing Practices are referenced off a domain found in the From header field which also assumes only one will be present. RFC2119 definition ,--- SHOULD This word, or the adjective RECOMMENDED, mean that there may exist _valid_ reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. '___ Section 3.8 Input Requirements states that verifiers SHOULD take reasonable steps to ensure that the messages they are processing are valid according to RFC5322, RFC2045, and any other relevant message format standard. Section 8.14 Attacks Involving Addition of Header Fields acknowledges: ,--- Many email implementations do not enforce [RFC5322] with strictness as discussed in Section 5.3 (Normalize the Message to Prevent Transport Conversions), DKIM processing is predicated on a valid mail message as its input. However, DKIM implementers should be aware of the potential effect of having loose enforcement by email components interacting with DKIM modules. '___ and further states: ,--- An MUA then might elect to render to the user the value of the first, or top, From: field. This may also be done simply out of the expectation that there is only one, where a find first algorithm would have the same result. Such code in an MUA can be exploited to fool the user if it is also known that the other From: field is the one checked by arriving message filters. Such is the case with DKIM; although the From: field must be signed, a malformed message bearing more than one From: field might only have the first (bottom) one signed, in an attempt to show the message with some DKIM passed annotation while also rendering the From: field that was not authenticated. (This can also be taken as a demonstration that DKIM is not designed to support author validation.) '___ This indicates the DKIM specification is seriously flawed. While DKIM may not offer author validation, it was intended to establish an accountable domain for the signed message content that at a minimum includes the From header field. There are NO valid reasons for a valid signature to include multiple From header fields! Allowing multiple From header fields is _EVIL_ and destroys DKIM's intended purpose as defined by prior work. Free email providers likely use DKIM to gain increased acceptance by taking advantage of their too big to block volumes. For these domains, their reputation is understood to offer little assurance of their overall integrity while perhaps limiting what is allowed in the domain portion of the From header field. By allowing a pre-pended From header field to not affect the validity of a DKIM signature according to the specification means the UNDERSTOOD source of a message can NEVER be trusted through the aid of DKIM. Those that phish by taking advantage of this neglected flaw are unlikely to affect the acceptance of any exploited high volume domain. DKIM could have avoided offering false assurances by not ignoring illegal multiple header fields per RFC5322 and defining such messages as resulting in invalid signatures. Unfortunately, when essential input checks are skipped, acceptance based upon DKIM's now potentially deceptive results may play an evil role that cannot be repaired through the use of reputation. The general goal of DKIM cryptographically binding at a minimum the From header field of the message content to a domain was to act as a trust basis for acceptance. DKIM also purports to allow incremental deployment without requiring additional undefined filtering be introduced in mail transfer or mail user agents. Clearly, the incremental deployment statement conflicts with the original goals due to the neglected input validation flaw. Details of this concern were stated in the tracker at: http://trac.tools.ietf.org/wg/dkim/trac/ticket/24 This
Re: Last Call: draft-holsten-about-uri-scheme-06.txt (The 'about' URI scheme) to Proposed Standard
Hello John, Thanks for your thoughts and proposals. Please see my comments (as one of the document co-authors) in-line. 17.06.2011 19:49, John C Klensin wrote: Given the controversies, I decided I needed to do a careful reading of this document. While I respect and appreciate what the authors are trying to do, as a would-be standards track specification, it is pretty troubling. I may agree here. It is troubling editorially as well. And here as well. I think all or most of the specific issues have been identified by others, so let me try a different perspective and a 10 km view. (1) There seems to be consensus that registering this URI as a mechanism for accessing built-in functionality and configuration information such as application information, preferences, or settings. (Text derived from the Abstract with configuration information, which may mean more to some readers, added and easter eggs dropped. Dropping easter eggs reflects other comments on the list and my opinion that it isn't worth the trouble to define. With regard to easter eggs I have no strong position. If it is troubling, I don't object to remove any mention of them from the document. Recommendation: Let's get it registered. That's what we're trying to do. But see the paragraph before Smaller issues. (2) The document itself reflects an attempt to define the undefinable. There is no cross-implementation interoperability issue here; if anything, the document should me more clear that it would be stupid to assume it. The document, nonetheless, tries to define what is done with some specific URIs in some places and then has to turn around and indicate that they may be used in entirely different ways in other places and should not be relied upon. In the process, it skips back and forth between being descriptive and being normative, with some definitions becoming circular in the process. That just isn't a good combination and some of it actually looks pretty silly. I may partly agree with you. Reading the document for a number of times I've also noticed this. A logical conclusion of everything aforementioned is below. about:blank is particularly troubling in that regard because the text essentially says that it is reserved except where it isn't. Recommendation: Choose one of the following and redo the document to match. Option 1: Do this descriptively. Strip it down as much as possible, more or less repeating the suggested language above. If the Wikipedia article really contains a better and more authoritative list of applications than the I-D text (and especially if it is being kept up to date), just reference it as a place where a non-normative listing and examples can be found. The effect of doing this at all would be to reserve the name for purposes internal to particular implementations of particular applications, not unlike RFC 1918 addresses. Option 2: Really try to make this normative wrt some subset of URI values. In this approach, stop the extremely confusing circling around. Indicate explicitly that about URIs have been used enough and in enough different circumstances that no application should assume that an about URI, if encountered, is actually its own and that due caution needs to be taken about non-conforming implementations. Then explicitly reserve, not onlyabout:blank, but everything the authors think is worth listing in Examples _and_ create an IANA registry for more of them. Actually your Option 2 is what we were trying to do all the time. However, considered a number of existing implementations, each one having their own behavior with regard to about URIs, I actually don' think is is possible. Option 1 seems to be much more realistic; in fact what we had in -00 (http://tools.ietf.org/id/draft-holsten-about-uri-scheme-00.txt) seems the best of any further version of the draft. -00 said that applications are free to resolve any about URI to any resource, either internal or external, or redirect to an alternative URI, with about:blank being the only exception. That's indeed better that what we have in the -06. Currently, I even question me whether we need to have an RFC published for the purpose of reservation of the scheme. The situation is probably the same as with the view-source URIs. It was ultimately registered with IANA upon a simple request whereas the initial intent was to publish the Informational RFC (see http://www.iana.org/assignments/uri-schemes/prov/view-source; https://datatracker.ietf.org/doc/draft-yevstifeyev-view-source-uri/). RFC 4395 intended the URI scheme registration to be lightweight - template provided is everything you need. So we could just process this registration in such way, as Permanent registration, without any separate specification. But, even the second approach is taken, the document should be really clear that all that the use of about: really tells someone is that it is application-specific and that a particular
Second Last Call: draft-hammer-hostmeta-16.txt (Web Host Metadata) to Proposed Standard -- feedback
Generally, it's hard for me to be enthusiastic about this proposal, for a few reasons. That doesn't mean it shouldn't be published, but I do question the need for it to be Standards Track as a general mechanism. Mostly, it's because I hasn't really seen much discussion of it as a general component of the Web / Internet architecture; AFAICT all of the interest in it and discussion of it has happened in more specialised / vertical places. The issues below are my concerns; they're not insurmountable, but I would have expected to see some discussion of them to date on lists like this one and/or the TAG list for something that's to be an Internet Standard. * XRD -- XRD is an OASIS spec that's used by OpenID and OAuth. Maybe I'm just scarred by WS-*, but it seems very over-engineered for what it does. I understand that the communities had reasons for using it to leverage an existing user base for their specific user cases, but I don't see any reason to generalise such a beast into a generic mechanism. * Precedence -- In my experience one of the most difficult parts of a metadata framework like this is specifying the combination of metadata from multiple sources in a way that's usable, complete and clear. Hostmeta only briefly mentions precedence rules in the introduction. * Scope of hosts -- The document doesn't crisply define what a host is. * Context of metadata -- I've become convinced that the most successful uses of .well-known URIs are those that have commonality of use; i.e., it makes sense to define a .well-known URI when most of the data returned is applicable to a particular use case or set of use cases. This is why robots.txt works well, as do most other currently-deployed examples of well-known URIs. Defining a bucket for potentially random, unassociated metadata in a single URI is, IMO, asking for trouble; if it is successful, it could cause administrative issues on the server (as potentially many parties will need control of a single file, for different uses -- tricky when ordering is important for precedence), and if the file gets big, it will cause performance issues for some use cases. * Chattiness -- the basic model for resource-specfic metadata in hostmeta requires at least two requests; one to get the hostmeta document, and one to get the resource-specific metadata after interpolating the URI of interest into a template. For some use cases, this might be appropriate; however, for many others (most that I have encountered), it's far too chatty. Many use cases find the latency of one extra request unacceptable, much less two. Many use cases require fetching metadata for a number of distinct resources; in this model, that adds a request per resource. I'd expect a general solution in this space to allow describing a map of a Web site and applying metadata to it in arbitrary ways, so that a client could fetch the document once and determine the metadata for any given resource by examining it. If hostmeta is designed for specific use cases and meets them well, that's great, but it shouldn't be sold as a general mechanism. So, I'm -1 on this going forward as a standards-track general mechanism. I wouldn't mind if it were Informational, or if it were Standards-Track but with a defined use case. Apologies for giving this feedback so late in the process; I knew hostmeta was there, just didn't have time to step back and think about it. Cheers, -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-ietf-mptcp-congestion-05.txt (Coupled Congestion Control for Multipath Transport Protocols) to Experimental RFC
The IESG has received a request from the Multipath TCP WG (mptcp) to consider the following document: - 'Coupled Congestion Control for Multipath Transport Protocols' draft-ietf-mptcp-congestion-05.txt as an Experimental 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 i...@ietf.org mailing lists by 2011-07-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Often endpoints are connected by multiple paths, but communications are usually restricted to a single path per connection. Resource usage within the network would be more efficient were it possible for these multiple paths to be used concurrently. Multipath TCP is a proposal to achieve multipath transport in TCP. New congestion control algorithms are needed for multipath transport protocols such as Multipath TCP, as single path algorithms have a series of issues in the multipath context. One of the prominent problems is that running existing algorithms such as standard TCP independently on each path would give the multipath flow more than its fair share at a bottleneck link traversed by more than one of its subflows. Further, it is desirable that a source with multiple paths available will transfer more traffic using the least congested of the paths, hence achieving resource pooling. This would increase the overall efficiency of the network and also its robustness to failure. This document presents a congestion control algorithm which couples the congestion control algorithms running on different subflows by linking their increase functions, and dynamically controls the overall aggressiveness of the multipath flow. The result is a practical algorithm that is fair to TCP at bottlenecks while moving traffic away from congested links. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mptcp-congestion/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-mpls-tp-linear-protection-07.txt (MPLS-TP Linear Protection) to Proposed Standard
The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS-TP Linear Protection' draft-ietf-mpls-tp-linear-protection-07.txt as a Proposed Standard 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 i...@ietf.org mailing lists by 2011-07-05. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Transport Profile for Multiprotocol Label Switching (MPLS-TP) is being specified jointly by IETF and ITU-T. This document addresses the functionality described in the MPLS-TP Survivability Framework document [SurvivFwk] and defines a protocol that may be used to fulfill the function of the Protection State Coordination for linear protection, as described in that document. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-linear-protection/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6272 on Internet Protocols for the Smart Grid
A new Request for Comments is now available in online RFC libraries. RFC 6272 Title: Internet Protocols for the Smart Grid Author: F. Baker, D. Meyer Status: Informational Stream: IETF Date: June 2011 Mailbox:f...@cisco.com, d...@cisco.com Pages: 66 Characters: 162815 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-baker-ietf-core-15.txt URL:http://www.rfc-editor.org/rfc/rfc6272.txt This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here. This document is not an Internet Standards Track specification; it is published for informational purposes. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6279 on Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement
A new Request for Comments is now available in online RFC libraries. RFC 6279 Title: Proxy Mobile IPv6 (PMIPv6) Localized Routing Problem Statement Author: M. Liebsch, Ed., S. Jeong, Q. Wu Status: Informational Stream: IETF Date: June 2011 Mailbox:lieb...@neclab.eu, sjje...@etri.re.kr, sunse...@huawei.com Pages: 14 Characters: 32954 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-netext-pmip6-lr-ps-06.txt URL:http://www.rfc-editor.org/rfc/rfc6279.txt Proxy Mobile IPv6 is the IETF Standard for network-based mobility management. In Proxy Mobile IPv6, mobile nodes are topologically anchored at a Local Mobility Anchor, which forwards all data for registered mobile nodes. The setup and maintenance of localized routing, which allows forwarding of data packets between two mobile nodes' Mobility Access Gateways without involvement of their Local Mobility Anchor in forwarding, is not considered. This document describes the problem space of localized routing in Proxy Mobile IPv6. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Network-Based Mobility Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6290 on A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE)
A new Request for Comments is now available in online RFC libraries. RFC 6290 Title: A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) Author: Y. Nir, Ed., D. Wierbowski, F. Detienne, P. Sethi Status: Standards Track Stream: IETF Date: June 2011 Mailbox:y...@checkpoint.com, wierb...@us.ibm.com, f...@cisco.com, pse...@cisco.com Pages: 22 Characters: 48891 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-ipsecme-failure-detection-08.txt URL:http://www.rfc-editor.org/rfc/rfc6290.txt This document describes an extension to the Internet Key Exchange Protocol version 2 (IKEv2) that allows for faster detection of Security Association (SA) desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text, we propose an extension to the protocol that allows for recovery immediately following the restart. [STANDARDS-TRACK] This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6308 on Overview of the Internet Multicast Addressing Architecture
A new Request for Comments is now available in online RFC libraries. RFC 6308 Title: Overview of the Internet Multicast Addressing Architecture Author: P. Savola Status: Informational Stream: IETF Date: June 2011 Mailbox:psav...@funet.fi Pages: 14 Characters: 30988 Obsoletes: RFC2908 I-D Tag:draft-ietf-mboned-addrarch-07.txt URL:http://www.rfc-editor.org/rfc/rfc6308.txt The lack of up-to-date documentation on IP multicast address allocation and assignment procedures has caused a great deal of confusion. To clarify the situation, this memo describes the allocation and assignment techniques and mechanisms currently (as of this writing) in use. This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the MBONE Deployment Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
