Re: voting system for future venues?
On 24/08/2011 23:12, Keith Moore wrote: Maybe there needs to be some sort of voting system for future venues. First of all, remember that the community asked for venue selections 2 to 3 years in advance. I don't think that many people can predict if they will attend a meeting 2 years from now. This proposal would require that the secretariat works out 3-4 proposals for meeting locations in great detail. That is a lot more work than the current approach: start with a few locations, discard options as one goes along. More work means more costs and thus higher meeting fees. Do we really want to increase fees just to have more options? You'd be eligible to vote if you'd attended an IETF anytime within the past, say, 2 years - or if you were willing to commit to attending the one you vote on if it wins. (say by putting down a deposit toward meeting fees). Instead of picking one venue, the committee would solicit bids from N (say 3-4) different venues within a geographic region.The bids would include: * room cost per night in the conference hotel * room cost per night in each of some small number of alternate hotels * locations of said hotels and nature of transportation between there and the conference venue * meeting fee for the entire week if that venue is chosen * other pertinent information (like what kind of food is nearby, what kind of facilities there are in or near the venue for impromptu gathering, what kinds of sightseeing opportunities there are, etc.) Looking at past discussions on the mailing lists, this list will be a lot longer. That way, everyone could figure his own travel costs, factor in his own willingness to stay further away for less cost, etc. Not true: it is not possible (nor sensible) to buy plane tickets 2 years in advance and a lot of things can change in between. Henk -- -- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 -- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
Including only the hotel costs may (I haven't crunched the numbers) be providing a very distorted view of the situation. In order to get the whole picture you have to include the meeting fees and air fare, at minimum. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC, travel and hotel prices
Dear IETF Administrative Oversight Committee, I hope that the questions below are in full compliance with BCP 101. If not, please feel free to ignore them. A few years back, the IAOC posted the following information: Venue I advantages include: * Rooms and meeting space under one roof * Many direct North American and International flights * Well known location for an IETF meeting Venue II advantages include: * Broader range of hotel guest room rates and less expensive * A new location, adjacent to a European-like historic district with numerous restaurants * Convention center a short walk from main hotels (several within a 5 minute walk) (a) Can the IAOC provide a list of advantages and disadvantages for venue selection? (b) Has the IAOC published (redacted) hotel contracts in the past? (c) Can the IAOC publish (redacted) hotel contracts for past venues? (d) Can the IAOC publish the list of members on the venue selection committee? (e) Has the IAOC ever held asked IETF participants to vote on the selection of a venue? (f) If the answer to (e) is yes, can the IAOC specify the voting system criteria? (g) Where can I find the policy or guideline for setting meeting dates five years in advanced? (h) Where can I find the policy or guideline for venue selection three years in advance? (i) Can the IAOC provide a list of confidential and non-confidential agreements it has entered into since the year 2010? (j) Has the IAOC taken any procedural variant decision? (k) What guidelines have been developed for regular operational decision making? Regards, -sm P.S. My opinion about the topic of travel and hotel prices is as follows: the church is near, but the way is icy, the tavern is far, but I will walk carefully. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 8/25/2011 3:52 PM, Doug Barton wrote: Including only the hotel costs may (I haven't crunched the numbers) be providing a very distorted view of the situation. In order to get the whole picture you have to include the meeting fees and air fare, at minimum. As I believe has been mentioned, hotel costs and meeting fees are intimately related. Air fares, of course, vary with locations, both that of the meeting and of the individual participant. For example, if I booked a round-trip to Taipei today, I could pay ~$300 but I had to search rather desperately to find a flight to QC for less than $2000 (both coach fares). That is one salutary effect of the current scheduling scheme, IMHO: it seems to spread the pain of airfare around a little bit... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 08/25/2011 02:36, Glen Zorn wrote: On 8/25/2011 3:52 PM, Doug Barton wrote: Including only the hotel costs may (I haven't crunched the numbers) be providing a very distorted view of the situation. In order to get the whole picture you have to include the meeting fees and air fare, at minimum. As I believe has been mentioned, hotel costs and meeting fees are intimately related. Right, that was sort of my point. :) Air fares, of course, vary with locations Also true, however if we're going to use charts and graphs to provide a metric of the effectiveness of the IAOC in this area it's important to take the whole picture into account. And while the regional rotation does spread the pain in a general way, there is a discussion point in regards to boutique venues vs. more pedestrian ones, and air fare is relevant to this issue as well. Note, I left out cost of food from my minimal data set since there are 2 independent variables inherent in that which (I believe probably) cancel this factor out over a reasonably long survey period. Individual taste (which can vary pretty widely) and the fact that local costs really are going to average out over time. But if someone wanted to make an argument that this should be included with the other 3 factors I would be quite easily persuaded. Meanwhile, count me in the more or less willing to believe that the IAOC is making the best of a difficult task + glad it's not me category. I've both been responsible for and assisted with conference planning and execution for groups both larger and smaller than the IETF, and it's an unbelievably difficult job. And to top it off, like so many other things in both life and business the better job you do this time the higher the expectations are next time. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Questionnaire to survey opinion concerning a possible redefinition of UTC
Since several RFCs rely on UTC and leap seconds (3339, 4765, 5905, etc), this questionnaire may be of interest for some persons [the Web page mentions two articles, if you are in a hurry, the first one is the PRO and the second one the CON]. One more week to comment. http://hpiers.obspm.fr/eop-pc/index.php?index=questionnaire QUESTIONNAIRE TO SURVEY OPINION CONCERNING A POSSIBLE REDEFINITION OF UTC Universal Time, the conventional measure of Earth rotation is the traditional basis for civil timekeeping. Clocks worldwide are synchronized via Coordinated Universal Time (UTC), an atomic time scale recommended by the Radiocommunications Sector of the International Telecommunications Union (ITU-R) and calculated by the Bureau International des Poids et Mesures (BIPM) on the basis of atomic clock data from around the world. UTC is computed from TAI by the introduction of leap seconds such that UTC is maintained within 1 second of UT1. Since 1972, these leap seconds have been added on December 31 or June 30, at the rate of about one every 18 months. Since 1 January 2009, 0:00 UTC, UTC-TAI= -34s. After years of discussions within the scientific community, a proposal to fundamentally redefine UTC will come to a conclusive vote in January 2012 at the ITU-R in Geneva. If this proposal is approved, it would be effective five years later. It would halt the intercalary adjustments known as leap seconds that maintain UTC as a form of Universal Time. Then, UTC would not keep pace with Earth rotation and the value of DUT1 would become unconstrained.Therefore UTC would no longer be directly useful for various technical applications which rely on it being less than 1 second from UT1. Such applications would require a separate access to UT1, such as through the publication of DUT1 by other means. The objective of the survey is to find out the strength of opinion for maintaining or changing the present system. Your response is appreciated before 31 August 2011 signature.asc Description: Digital signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On Aug 25, 2011, at 2:13 AM, Henk Uijterwaal wrote: On 24/08/2011 23:12, Keith Moore wrote: Maybe there needs to be some sort of voting system for future venues. First of all, remember that the community asked for venue selections 2 to 3 years in advance. I don't think that many people can predict if they will attend a meeting 2 years from now. This proposal would require that the secretariat works out 3-4 proposals for meeting locations in great detail. That is a lot more work than the current approach: start with a few locations, discard options as one goes along. More work means more costs and thus higher meeting fees. I don't think it should be (much) more work to let attendees make the final choice. (Though I admit that it's possible that presenting all of that information in the best possible light for each venue might end up being time consuming.) But on what basis are the options discarded by IAOC, if the different options aren't examined to at least the level of detail that I suggested? Do we really want to increase fees just to have more options? Not more options, but more transparency into the selection and more assurance that the selection is made on the basis of what people really want or don't want. You'd be eligible to vote if you'd attended an IETF anytime within the past, say, 2 years - or if you were willing to commit to attending the one you vote on if it wins. (say by putting down a deposit toward meeting fees). Instead of picking one venue, the committee would solicit bids from N (say 3-4) different venues within a geographic region.The bids would include: * room cost per night in the conference hotel * room cost per night in each of some small number of alternate hotels * locations of said hotels and nature of transportation between there and the conference venue * meeting fee for the entire week if that venue is chosen * other pertinent information (like what kind of food is nearby, what kind of facilities there are in or near the venue for impromptu gathering, what kinds of sightseeing opportunities there are, etc.) Looking at past discussions on the mailing lists, this list will be a lot longer. No doubt. That way, everyone could figure his own travel costs, factor in his own willingness to stay further away for less cost, etc. Not true: it is not possible (nor sensible) to buy plane tickets 2 years in advance and a lot of things can change in between. True. Though broadly speaking, if it's expensive to fly somewhere today, it's unlikely to be cheap to fly there in two years. (Admittedly, the real gotcha in Quebec seems to have been that there were so few seats available that the few low-priced fares were quickly exhausted. Everyone could get quotes two years in advance and all see the same cheap fares, even if those fares were only available for say 10 seats per day.) Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Ole == Ole Jacobsen o...@cisco.com writes: Ole * Sticking to our fixed dates, published up to 5 years in Ole advance. Ole I think you will find that the one-roof solution does indeed Ole lead to fairly expensive HQ properties, this is more or less Ole true all over the world and is currently made much worse by the Ole weak dollar. The fixed date restriction (which is good in my Ole view) also contributes to challenges with venue Ole availability. We been told more than once that if you do it a Ole week later or earlier... Given that we are now booking three years in advance (vs 1 year that occured 5 years ago), perhaps it is time to change our policy to publish the dates only three years in advance. We still have the list of conflicts/avoidances to deal with. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 25 Aug 2011, at 14:58, Nathaniel Borenstein wrote: I'm not saying this is the whole problem -- and it would be interesting to graph US meetings separately -- but the weakness of the dollar has to be a factor. -- Nathaniel The graphs are really interesting, but the fact remains you can book a room for a week at Minneapolis or Prague in IETF82 week for nearly $100 a day less than the cost of the Hyatt in Taipei, and that's just the public hotel rate, nothing negotiated. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Ole, In the (somewhat far) past, my memory was that the IETF rate was *less* then the normal available rate. This trend to higher rates is something I only remember seeing over the last 5 or so years. Perhaps my memory is just flawed, as I haven't done the work to verify this, but I don't think so. I think in the spirit of transparency we really need to understand why this trend has occurred. From looking at the list of things we get for the IETF rate, the only thing I see in the list that is really important to the individuals paying the room-fees is in-room (typically) IETF-class internet. Breakfast is great, but it is included only when this is the norm for the region/hotel, so really isn't a real benefit compared to rack rates. I strongly feel that the free or subsidized meeting rooms should come out of the meeting fees, not *hidden* in the hotel rates. You also don't mention the free hotel rooms/suites. Again the value here and subsidy in the IETF rates really should be known, but in either case, these too should come out of the meeting fees. I personally think the issues to focus on/fix are the lack of transparency and the current approach of distributing meeting costs to the hotel rate. Lou On 8/23/2011 2:07 PM, Ole Jacobsen wrote: You said: At root is that we are trying to negotiate a purchase at a discounted price without committing to buying any particular number of rooms, versus only a limited number of possible sellers. When negotiating a group rate we actually ARE committing to buying a certain number of rooms (the room block). There are certainly pros and cons with group rates. On the pro side: guaranteed rate (but not necessarily the absolute lowest available at any time), included benefits (breakfast, Internet, if applicable), free or subsidized meeting rooms where applicable. On the cons side is of course the cancellation policy (not that it has to be as onerous as this one). Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo ___ 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: [IETF] Re: Hyatt Taipei cancellation policy?
From: Warren Kumari [war...@kumari.net] And I've concluded that the IAOC have a crappy job to do and that folk like to kvetch. +1 The IAOC does a remarkably good job given the difficulty of the optimization problem. Just over the last two years, I'm amazed by the number of vastly different places we've had meetings, and I (as a non-speaking foreigner in many of them) have had no serious difficulties with any of them. Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
Ole == Ole Jacobsen o...@cisco.com writes: Ole The Sofitel Manila is where APRICOT 2009 was held. A great Ole venue, possibly even large enough to hold an IETF (I am not Ole sure), *and* the rate (at the time) at 7,525 Pesos was pretty Ole good. Today it is $177 which is still pretty good. The question Ole is: would the IETF go to the Philippines for a meeting. It's Ole worth finding out. I can't find a flight that gets me there in less than 2 days from Canada. I tried for November. Most transit US (a -0.5 for me), many connect in Tokyo or Hong Kong or Seoul... hmm. travel on Friday is easier than Saturday. The price is about the same as I paid for Prague. The cheapest connects in Guam, which I've always wanted to do. (Of course, the price to Tokyo or Hong Kong or Seoul will be higher..) But, what will the price be, once we get our block? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
Michael, I think we could expect a room block cost similar to that of APRICOT 2009, but the dollar has tanked since then so even cheap places in Asia like this aren't so cheap any longer. And, yes, it would be hard go get to for some value of hard. I wasn't proposing we go there. As Nathaniel pointed out, some currencies have really risen against the dollar. It isn't that long ago that the yen was well above 100 to the dollar (the mental calculation point), somewhere in the 110-120 range actually, but TODAY it is at 76-77 yen to the dollar. So, a hotel room back then (the peak was July 2007 at 123 yen to the dollar), say at 15,000 yen would cost ~ $121. Today that same room, still at 15,000 yen will cost ~ $197, heck let's call it $200. The Sing dollar and Oz dollar have done similar things, Canadian too :-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Thu, 25 Aug 2011, Michael Richardson wrote: Ole == Ole Jacobsen o...@cisco.com writes: Ole The Sofitel Manila is where APRICOT 2009 was held. A great Ole venue, possibly even large enough to hold an IETF (I am not Ole sure), *and* the rate (at the time) at 7,525 Pesos was pretty Ole good. Today it is $177 which is still pretty good. The question Ole is: would the IETF go to the Philippines for a meeting. It's Ole worth finding out. I can't find a flight that gets me there in less than 2 days from Canada. I tried for November. Most transit US (a -0.5 for me), many connect in Tokyo or Hong Kong or Seoul... hmm. travel on Friday is easier than Saturday. The price is about the same as I paid for Prague. The cheapest connects in Guam, which I've always wanted to do. (Of course, the price to Tokyo or Hong Kong or Seoul will be higher..) But, what will the price be, once we get our block? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ 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: voting system for future venues?
Maybe next we try Ulan Bator, Mongolia Warm Regards, Anshuman Sent from my BlackBerry® Smartphone, regret typo's! -Original Message- From: Ole Jacobsen o...@cisco.com Sender: ietf-boun...@ietf.org Date: Thu, 25 Aug 2011 07:33:09 To: Michael Richardsonm...@sandelman.ca Reply-To: Ole Jacobsen o...@cisco.com Cc: IETF-Discussion listietf@ietf.org Subject: Re: voting system for future venues? Michael, I think we could expect a room block cost similar to that of APRICOT 2009, but the dollar has tanked since then so even cheap places in Asia like this aren't so cheap any longer. And, yes, it would be hard go get to for some value of hard. I wasn't proposing we go there. As Nathaniel pointed out, some currencies have really risen against the dollar. It isn't that long ago that the yen was well above 100 to the dollar (the mental calculation point), somewhere in the 110-120 range actually, but TODAY it is at 76-77 yen to the dollar. So, a hotel room back then (the peak was July 2007 at 123 yen to the dollar), say at 15,000 yen would cost ~ $121. Today that same room, still at 15,000 yen will cost ~ $197, heck let's call it $200. The Sing dollar and Oz dollar have done similar things, Canadian too :-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Thu, 25 Aug 2011, Michael Richardson wrote: Ole == Ole Jacobsen o...@cisco.com writes: Ole The Sofitel Manila is where APRICOT 2009 was held. A great Ole venue, possibly even large enough to hold an IETF (I am not Ole sure), *and* the rate (at the time) at 7,525 Pesos was pretty Ole good. Today it is $177 which is still pretty good. The question Ole is: would the IETF go to the Philippines for a meeting. It's Ole worth finding out. I can't find a flight that gets me there in less than 2 days from Canada. I tried for November. Most transit US (a -0.5 for me), many connect in Tokyo or Hong Kong or Seoul... hmm. travel on Friday is easier than Saturday. The price is about the same as I paid for Prague. The cheapest connects in Guam, which I've always wanted to do. (Of course, the price to Tokyo or Hong Kong or Seoul will be higher..) But, what will the price be, once we get our block? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ 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: Hyatt Taipei cancellation policy?
Lou == Lou Berger lber...@labn.net writes: Lou Ole, In the (somewhat far) past, my memory was that the IETF Lou rate was *less* then the normal available rate. This trend to Lou higher rates is something I only remember seeing over the last Lou 5 or so years. Perhaps my memory is just flawed, as I haven't Lou done the work to verify this, but I don't think so. Yes, I agree. It seems that it has occured since we started booking the events many years in advance. When we booked at the last minute, and didn't know even where the meeting was going to be more than two IETFs in advance, the room rates were better. Lou I personally think the issues to focus on/fix are the lack of Lou transparency and the current approach of distributing meeting Lou costs to the hotel rate. It's more than that, but until we have this fixed, we can't know how much more. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [websec] Last Call: draft-ietf-websec-origin-04.txt (The Web Origin Concept) to Proposed Standard
Below a few late comments.. 6. Serializing Origins - It really really seems that the two algorithms need to be swapped (the first one converts to ASCII, but the second does not). - Also, I'd prefer a declarative definition. 7. The HTTP Origin header - header *field* - the syntax doesn't allow multiple header fields, and the prose says clients MUST NOT generate them; what is the recipient supposed to do when it get's multiple instances anyway? Is the default approach (ignoring them all) good enough? Do we need to warn recipients so that they check? 11. References - the WEBSOCKETS reference should be updated (if a new draft is produced) Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Hi, I would like to propose that this draft explicitly stipulate whether or not it covers per-interface model. I think it is essential to avoid confusion and clarify the appropriate I-D to discuss OAM solutions for the per-interface model. Per-interface model is one of the two OAM maintenance models in MPLS-TP networks which is specified in section 3 of draft-ietf-mpls-tp-oam-framework. The solution for the per-interface model is under discussion also in the per-interface MIP draft ( http://tools.ietf.org/html/draft-farrel-mpls-tp-mip-mep-map-04 ). If the on-demand-cv-06 covers the OAM solution for per-interface model, the discussion for on-demand CV and route tracing must be removed from the mip-mep-map draft. Otherwise, the mip-mep-map draft has to cover the solutions for on-demand CV and route tracing. I also think that it is important to clarify the comments from Mr. Zhenlong Cui in the draft, whose email is attached at the bottom. It is important to make clear for what purpose the IF_Num is used. It also seems important to clarify the responder's behavior, because the ambiguity will definitely lead to interoperability issues. Thank you in advance. Best regards, Yoshinori Koike (2011/08/25 15:17), Zhenlong Cui wrote: Hi, I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd like to make sure it is not lost. 2.1. New address type for Downstream Mapping TLV The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of IF_NUM in [I-D.ietf-mpls-tp-identifiers]) for both ingress and egress interfaces, as well as multipath information is included in the format and MAY be present. I believe the IF_Num can be used for per-interface MIP model. But I'm not sure why we need use both ingress IF_Num and egress IF_Num in a DSMAP TLV. I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-identifiers]. e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using IF_Num, but there is no Ingress_IF::Egress_IF. - IF_ID IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. - MIP ID For a MIP which is associated with particular interface, we simply use the IF_ID (see Section 4) of the interfaces which are cross- connected. If have any special means in the IF_Num, I think MUST mention it clearly. Also I feeling that this draft have to clarify the responder's behavior for each IF information of the IF_Num. Best regards, zhenlong -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, August 11, 2011 10:46 PM To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call:draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf-mpls-tp-on-demand-cv-06.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 ietf@ietf.org mailing lists by 2011-08-25. 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 Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls -- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On Aug 24, 2011, at 20:21 , Brian E Carpenter wrote: On 2011-08-25 13:42, somebody other than Ole Jacobsen wrote: I agree that IAOC should ensure that there are inexpensive hotels nearby so that those with a tight budget can save money. This is the key point. The anchor hotel, especially when there is a convention centre involved, is quite likely to be overpriced. Overpriced is a value judgement subject to interpretation of market signals. The IAOC should, IMNSHO, ensure that an adequate set of moderately priced hotels within a short walk of the venue is available. That seems to be the problem in Taipei; the backup hotel is useless and not particularly cheap. Brian ___ 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: Hyatt Taipei cancellation policy?
- Original Message - From: Thomas Nadeau tnad...@lucidvision.com To: Alia Atlas akat...@gmail.com Cc: Sam Hartman hartmans-i...@mit.edu; Dave CROCKER dcroc...@bbiw.net; ietf@ietf.org Sent: Wednesday, August 24, 2011 10:39 PM On Aug 24, 2011, at 4:33 PM, Alia Atlas wrote: On Wed, Aug 24, 2011 at 4:30 PM, Dave CROCKER dcroc...@bbiw.net wrote: On 8/24/2011 1:27 PM, Sam Hartman wrote: Can you start by backing up the assertion that the community has vigrously expressed a preference for interesting venues? I may just need a new IETF community:-) gosh, I hadn't thought that that was less than obvious, given the vote for quebec and many, many comments about venue choice over the years. I'm one who really liked Minneapolis - we had excellent meeting space, places to run into each other, reasonable food access, and a clueful hotel. Is it interesting to go to new places? Sure and if I'm lucky I might get a morning or afternoon to look around. Would I be perfectly happy going to the same 2-3 places every year? Absolutely. I am with you on that. I do not attend IETFs as a vacation and sight-seeing opportunity. tp Yes, I too go to work, and would rate Minneapolis in the top three, with Atlanta perhaps just above it. Tom /tp --Tom Alia ___ 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: [OSPF] [karp] Last Call: draft-ietf-ospf-auth-trailer-ospfv3-05.txt (Supporting Authentication Trailer for OSPFv3) to Proposed Standard
Hi Manav, On Aug 24, 2011, at 10:51 AM, Bhatia, Manav (Manav) wrote: Hi Acee, We change the hex that's repeated in the Apad from 0x878FE1F3 to 0x878FE1F4. This value will be unique for OSPFv3. Other protocols that use this mechanism must use a different value of Apad - you could think of this as salting the Apad. Could we simply use the OSPFv3 protocol number, 89, in the Apad, e.g., 0x898FE1F4, (or at least the first instance of Apad). Otherwise, we probably need a registry for IANA Apads. I meant 0x898FE1F3 as to not change the last 3 octets of the existing HMAC-SHAx Apad. We would still need an IANA registry of Apads unless youre thinking of using the IP protocol type as the first octet of the Apad. That's exactly what I'm proposing. If it's the latter, then OSPFv3 and OSPFv2 would share the same Apad, which would defeat the purpose of the whole exercise. Are you forgetting about the version as the first nibble of the header? This would also not work for multiple protocols that ride over UDP and TCP. BFD and RIP would end up using the same Apad as their IP protocol is the same. UDP/TCP protocols would need a scheme that includes their well-know port - perhaps, the second octet of the first instance of Apad ;^). We thus need a unique Apad that each standard can define if we want to protect ourselves from the attack that Sam describes. Thanks, Acee Cheers, Manav smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [OSPF] [karp] Last Call: draft-ietf-ospf-auth-trailer-ospfv3-05.txt (Supporting Authentication Trailer for OSPFv3) to Proposed Standard
On Aug 24, 2011, at 12:05 PM, Acee Lindem wrote: Hi Manav, On Aug 24, 2011, at 10:51 AM, Bhatia, Manav (Manav) wrote: Hi Acee, We change the hex that's repeated in the Apad from 0x878FE1F3 to 0x878FE1F4. This value will be unique for OSPFv3. Other protocols that use this mechanism must use a different value of Apad - you could think of this as salting the Apad. Could we simply use the OSPFv3 protocol number, 89, in the Apad, e.g., 0x898FE1F4, (or at least the first instance of Apad). Otherwise, we probably need a registry for IANA Apads. I meant 0x898FE1F3 as to not change the last 3 octets of the existing HMAC-SHAx Apad. We would still need an IANA registry of Apads unless youre thinking of using the IP protocol type as the first octet of the Apad. That's exactly what I'm proposing. If it's the latter, then OSPFv3 and OSPFv2 would share the same Apad, which would defeat the purpose of the whole exercise. Are you forgetting about the version as the first nibble of the header? Meant the first byte of course - first nibble is for IPv4 vs IPv6 ;^) This would also not work for multiple protocols that ride over UDP and TCP. BFD and RIP would end up using the same Apad as their IP protocol is the same. UDP/TCP protocols would need a scheme that includes their well-know port - perhaps, the second octet of the first instance of Apad ;^). We thus need a unique Apad that each standard can define if we want to protect ourselves from the attack that Sam describes. Thanks, Acee Cheers, Manav smime.p7s___ OSPF mailing list o...@ietf.org https://www.ietf.org/mailman/listinfo/ospf smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
GEN-ART review of draft-ietf-krb-wg-clear-text-cred-02
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-krb-wg-clear-text-cred-02 Reviewer: Kathleen M. Moriarty Review Date: 08-24-11 IETF LC End Date: 08-25-11 IESG Telechat date: 08-25-11 Summary: The document is ready with nits Major issues: Minor issues: Nits/editorial comments: Introduction: Consider changing from: There are applications which need to transfer Kerberos credentials between them without having a prior relationship with established Kerberos keys. To: There are applications which need to transfer Kerberos credentials between them without having established a prior relationship with Kerberos keys. Consider breaking the following sentence into two sentences, it is a little difficult to read as a number of concepts are introduced within this one sentence: In the SAML application, the Identity Provider (IdP) somehow obtains a Kerberos service ticket from the Kerberos Key Distribution Center (KDC) when required by the SAML system and transfers the credential to a Service Provider (SP) within an attribute statement. Security Considerations section: Consider changing the following From: The use of an unencrypted form of the KRB-CRED message MUST only be used with a transport where sender and recipient identities can been established to be known to each other. To: The use of an unencrypted form of the KRB-CRED message MUST only be used with a transport where sender and recipient identities can been established and are known to each other. Consider changing from: Examples of transports which MAY be securely used to transport an unencrypted KRB-CRED message would include Transport Layer Security (TLS) [RFC5246] where mutual authentication has been established and those encoded within encrypted and signed SAML Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] statement. To: Examples of transports which MAY be securely used to transport an unencrypted KRB-CRED message would include Transport Layer Security (TLS) [RFC5246], where mutual authentication has been established, and a SAML Security Assertion Markup Language (SAML) 2.0 [OASIS.saml-core-2.0-os] statement that is encrypted and signed. Thanks, Kathleen ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On Wed, 2011-08-24 at 16:27 -0400, Sam Hartman wrote: Dave == Dave CROCKER d...@dcrocker.net writes: Dave ps. As a personal aside, I'll note that I've lobbied rather Dave vigorously for venues that entail less travel effort, by Dave eliminating the additional hop needed to get from a major hub. Dave Note that that has gotten essentially zero support from the Dave community. The community has vigrously expressed a preference Dave for interesting venues rather than ones that are chosen Dave solely for logistics convenience. Can you start by backing up the assertion that the community has vigrously expressed a preference for interesting venues? I may just need a new IETF community:-) I agree. I think that there is a vocal minority that wants this. I don't think that community as a whole really cares. We had this huge debate about the number of times (down to fractions of times) to visit each area of the world so as to increase participation and we then have locations that make it difficult to get to or expensive or both and expensive to get to which limits participation. I like Santa Clara, CA geoff ___ 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: Hyatt Taipei cancellation policy?
On Wed, 2011-08-24 at 15:28 -0400, Sam Hartman wrote: 1) We don't have to go to any particular location. There has been an assumption made by people in this discussion that sometimes when we pick locations with particularly expensive hotels, we'll get particularly expensive meetings. That's great except that we were the ones who chose to go to those locations. If we can't meet our cost targets at a location, go somewhere else. Sam makes a really good point here. We didn't have to go to Taipei. For some reason we chose to go to Taipei. When the IAOC was looking at places years ago was the dollar so strong that the hotel was cheap - I doubt it. It was probably just as expensive back then. It should have just been dropped from the list and the city as wel. The hotel (and host if there was on) could/should have been told - sorry too expensive. There was never a requirement to go to Taipei. There was never a requirement to go to Maastricht with the 3 train changes and hotels spread out and not under a single roof, awful cancellation policy (unless you booked it separately from the IETF). Nice place, but no one ordered us to go to Maastricht. I liked Hiroshima, but even it was not easy to get to (multiple trains). We seem to be limiting attendance to people from large companies just so that we can meet everywhere in the world. If it isn't relatively inexpensive then we say, sorry we can't go there. So what. We don't have to visit every country. I know that this is blasphemous but why can't we meet in just a couple of the same places over and over again -- yeah it's boring for those that want to be a tourist, but I go to work and would prefer a venue that has good/easy access (major airport nearby) with a cheapish hotel and a decent cancellation policy. geoff PS - Lets just go to Minneapolis 3 times a year - bet we can get a great rate and the US dollar is on-sale! ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Maybe the majority doesn't care one way or the other - they will just go wherever the meetings are held in which case: let's make them easy to get to cheap decent food one roof (with other hotels near-by) cheap and easy to get to You could pick Rosemont, IL (next to O'hare) for every meeting (oops, sorry - misses on decent food). geoff On Wed, 2011-08-24 at 13:23 -0700, Dave CROCKER wrote: On 8/24/2011 1:18 PM, Peter Saint-Andre wrote: As long as a relatively large percentage of IETF folks see meetings as an opportunity to sight-see, I don't think we'll see much support for rotating among a small set of major hub locations. +1 But it's worse than relatively large percent. There's absolutely no minority constituency that is vocal about wanting this to change. That's why I declared myself giving up on this topic. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On Wed, 2011-08-24 at 14:10 -0700, Ole Jacobsen wrote: On Wed, 24 Aug 2011, Dave CROCKER wrote: ps. Underlying any sort of change to the model is a change in the nature of host/sponsor recruitment. The current approach uses new venues to aid in finding new sponsors. Not quite. But you are correct that sponsors/hosts often strongly influence the choice of venue and let's not forget that there are places (China for example) where we could NOT do a meeting without a host [regardless of any financial considerations]. There may not be many such places, but the do exist. I'm confused. I heard earlier that we are picking sites 3 years ahead of time, but that sponsorship is something that happens 18 months or less. So we are not picking venues based on sponsorship or are we? If we didn't have a sponsor how much would the meeting fee increase? $100 or $200? That is more than offset by the increased cost of the hotel ($150/night vs $200/night). geoff PS - I liked Philadelphia Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-krb-wg-otp-preauth-18 Reviewer: David L. Black Review Date: August 24, 2011 IETF LC End Date: August 29, 2011 Summary: This draft is on the right track but has open issues, described in the review. This is a tightly written draft on one-time-password token-based preauthentication for Kerberos. The text does a good job of tightly specifying the algorithms and protocol steps; the resulting text is a bit dense to read, but provides the necessary precision for implementation. Disclaimer - the draft author and this reviewer work for different organizations in the same company (EMC). I found two open issues, both of which are relatively minor: [1] In section 6.1 at the top of p.28, I don't believe that the use of lower case recommended is a strong enough warning about the danger in using anonymous PKINIT because it exposes the OTP value: It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it is used with other algorithms such as those with short OTP values. At a minimum, that warning should be in upper-case: It is therefore RECOMMENDED that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. Beyond that, the security issue in the first sentence may be severe enough to justify a prohibition, so the following would also be acceptable: Therefore anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. [2] In section 5, the first paragraph in the IANA considerations is unclear, and following its reference to section 4.1, I don't see any clarifying text there either. I think Sections 4.1 and 4.2 need to say that the value of otp-algID is a URI obtained from the PSKC Algorithm URI Registry, and the first paragraph in section 5 should say that URIs for otp-algID are to be registered in that registry, see RFC 6030. I also found a couple of minor nits: In Section 1.1, please expand the FAST acronym on first use. In section 2.4, the following sentence is potentially confusing: For example, event-based tokens may drift since the counter on the token is incremented every time the token is used but the counter on the server is only incremented on an authentication. Similarly, the clocks on time-based tokens may drift. The confusion arises because the resync mechanism described in that section causes the client to use the next token value. By itself, that won't help when an event based has gotten ahead of the server; using the next value only puts the token further ahead. Similarly, by itself, this mechanism does not help if the token clock has drifted ahead of the server clock, but does help if the token clock has drifted behind. A little more explanation of what the server can do to take advantage of this mechanism (e.g., how to deal with an event-based token that is ahead of the server) would reduce the confusion. idnits 2.12.12 generated a bunch of warnings, none of which require any change to the draft. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 david.bl...@emc.com Mobile: +1 (978) 394-7754 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard
Hi, I have sent some questions regarding the IF_Num of DSMAP TLV before. I'd like to make sure it is not lost. 2.1. New address type for Downstream Mapping TLV The new address type indicates that no address is present in the DSMAP or DDMAP TLV. However, IF_Num information (see definition of IF_NUM in [I-D.ietf-mpls-tp-identifiers]) for both ingress and egress interfaces, as well as multipath information is included in the format and MAY be present. I believe the IF_Num can be used for per-interface MIP model. But I'm not sure why we need use both ingress IF_Num and egress IF_Num in a DSMAP TLV. I can't find this case (Ingress_IF::Egress_IF) in [I-D.ietf-mpls-tp-identifiers]. e.g.) the following are defined in [I-D.ietf-mpls-tp-identifiers] using IF_Num, but there is no Ingress_IF::Egress_IF. - IF_ID IF_ID is a 64-bit identifier formed as Node_ID::IF_Num. - MIP ID For a MIP which is associated with particular interface, we simply use the IF_ID (see Section 4) of the interfaces which are cross- connected. If have any special means in the IF_Num, I think MUST mention it clearly. Also I feeling that this draft have to clarify the responder's behavior for each IF information of the IF_Num. Best regards, zhenlong -Original Message- From: mpls-boun...@ietf.org [mailto:mpls-boun...@ietf.org] On Behalf Of The IESG Sent: Thursday, August 11, 2011 10:46 PM To: IETF-Announce Cc: m...@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-on-demand-cv-06.txt (MPLSOn-demand Connectivity Verification and Route Tracing) toProposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS On-demand Connectivity Verification and Route Tracing' draft-ietf-mpls-tp-on-demand-cv-06.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 ietf@ietf.org mailing lists by 2011-08-25. 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 Label Switched Path Ping (LSP-Ping) is an existing and widely deployed Operations, Administration and Maintenance (OAM) mechanism for Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). This document describes extensions to LSP-Ping so that LSP- Ping can be used for On-demand Connectivity Verification of MPLS Transport Profile (MPLS-TP) LSPs and Pseudowires. This document also clarifies procedures to be used for processing the related OAM packets. Further, it describes procedures for using LSP-Ping to perform Connectivity Verification and Route Tracing functions in MPLS-TP networks. Finally this document updates RFC 4379 by adding a new address type and requesting an IANA registry. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-on-demand-cv/ No IPR declarations have been submitted directly on this I-D. ___ mpls mailing list m...@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 25/08/2011 13:06, Keith Moore wrote: On Aug 25, 2011, at 2:13 AM, Henk Uijterwaal wrote: But on what basis are the options discarded by IAOC, if the different options aren't examined to at least the level of detail that I suggested? I think it is more a continuous process. Start with a number of options, investigate them in more detail, discard options as one goes along, work out the 100,000 little details that need to be taken care of with the most promising site only, then decide if the overal package is a good one. If not, repeat for the next site. Do we really want to increase fees just to have more options? Not more options, but more transparency into the selection and more assurance that the selection is made on the basis of what people really want or don't want. There are a lot of requirements, 1,000 participants who all prioritize them in different ways and there is no venue that meets all requirements. Thus whoever makes the selection will have to weigh all requirements and find a solution that is optimal for most people. The IETF has picked a model were a small set of people make this selection for the rest of the group. If you don't trust that they are trying their best to make the optimal selection, then there is a fundamental problem that cannot be solved by providing more documents, voting processes, etc. Not true: it is not possible (nor sensible) to buy plane tickets 2 years in advance and a lot of things can change in between. True. Though broadly speaking, if it's expensive to fly somewhere today, it's unlikely to be cheap to fly there in two years. Not always, here in Europe, one often sees price-fights between various airlines if a destination suddenly becomes popular for some reason or another. (And also the opposite: prices go up if the number of competitors on a route drops). Henk -- -- Henk Uijterwaal Email: henk(at)uijterwaal.nl http://www.uijterwaal.nl Phone: +31.6.55861746 -- There appears to have been a collective retreat from reality that day. (John Glanfield, on an engineering project) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
Hi Sam, Thanks for the quick response? I'll watch for the new text on anonymous PKINIT. Why should we require that alg-ids be registered URIs? That's not my concern - the existing first paragraph of the IANA considerations section in the draft requires IANA registration (or at least tries to) by pointing to the PSKC registry. My concern is that if this is going to be done, it needs to be done right (duh!), and the current text is insufficient. Please take the issue of whether to use IANA for this purpose up with Gareth and the WG. I have no problem with the IETF registering its algorithms there, or us encouraging people to register them there, but it's a URI. What purpose is served by forcing registration? Hmm - more than one URI for the same algorithm might cause interoperability problems. Thanks, --David -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Wednesday, August 24, 2011 10:04 PM To: Black, David Cc: Richards, Gareth; gen-...@ietf.org; ietf@ietf.org; ietf-krb...@lists.anl.gov; hartmans- i...@mit.edu; stephen.farr...@cs.tcd.ie Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 david.bl...@emc.com writes: [1] In section 6.1 at the top of p.28, I don't believe that the use of lower case recommended is a strong enough warning about the danger in using anonymous PKINIT because it exposes the OTP value: It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it is used with other algorithms such as those with short OTP values. At a minimum, that warning should be in upper-case: It is therefore RECOMMENDED that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. Beyond that, the security issue in the first sentence may be severe enough to justify a prohibition, so the following would also be acceptable: Therefore anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. I definitely agree that we should use RFC 2119 language. Note that WG participants have questioned this text in last call for other reasons. Many implementations use anonymous pkinit in a mode where the KDC's certificate is verified--that is the client is anonymous but the KDC is identified through a PKI. WG participants believe (and I agree) that the security concern does not apply at all in this case. So, the text needs reworking. [2] In section 5, the first paragraph in the IANA considerations is unclear, and following its reference to section 4.1, I don't see any clarifying text there either. I think Sections 4.1 and 4.2 need to say that the value of otp-algID is a URI obtained from the PSKC Algorithm URI Registry, and the first paragraph in section 5 should say that URIs for otp-algID are to be registered in that registry, see RFC 6030. Why should we require that alg-ids be registered URIs? I.E. what is wrong with me using http://algorithms.painless-security.com/otp/best-thing-since-unsliced-bread (or a tag URI if you like) for my OTP algorithm? I have no problem with the IETF registering its algorithms there, or us encouraging people to register them them, but it's a URI. What purpose is served by forcing registration? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18
Make that - Thanks for the quick response. (off-by-one key error ...) Thanks, --David -Original Message- From: Black, David Sent: Thursday, August 25, 2011 9:14 AM To: Sam Hartman Cc: Richards, Gareth; gen-...@ietf.org; ietf@ietf.org; ietf-krb...@lists.anl.gov; stephen.farr...@cs.tcd.ie; Black, David Subject: RE: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 Hi Sam, Thanks for the quick response? I'll watch for the new text on anonymous PKINIT. Why should we require that alg-ids be registered URIs? That's not my concern - the existing first paragraph of the IANA considerations section in the draft requires IANA registration (or at least tries to) by pointing to the PSKC registry. My concern is that if this is going to be done, it needs to be done right (duh!), and the current text is insufficient. Please take the issue of whether to use IANA for this purpose up with Gareth and the WG. I have no problem with the IETF registering its algorithms there, or us encouraging people to register them there, but it's a URI. What purpose is served by forcing registration? Hmm - more than one URI for the same algorithm might cause interoperability problems. Thanks, --David -Original Message- From: Sam Hartman [mailto:hartmans-i...@mit.edu] Sent: Wednesday, August 24, 2011 10:04 PM To: Black, David Cc: Richards, Gareth; gen-...@ietf.org; ietf@ietf.org; ietf-krb...@lists.anl.gov; hartmans- i...@mit.edu; stephen.farr...@cs.tcd.ie Subject: Re: Gen-ART review of draft-ietf-krb-wg-otp-preauth-18 david.bl...@emc.com writes: [1] In section 6.1 at the top of p.28, I don't believe that the use of lower case recommended is a strong enough warning about the danger in using anonymous PKINIT because it exposes the OTP value: It is therefore recommended that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC and that careful consideration be made of the security implications before it is used with other algorithms such as those with short OTP values. At a minimum, that warning should be in upper-case: It is therefore RECOMMENDED that anonymous PKINIT not be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. Beyond that, the security issue in the first sentence may be severe enough to justify a prohibition, so the following would also be acceptable: Therefore anonymous PKINIT SHALL NOT be used with OTP algorithms that require the OTP value to be sent to the KDC. In addition, the security implications should be carefully considered before anonymous PKINIT is used with other algorithms such as those with short OTP values. I definitely agree that we should use RFC 2119 language. Note that WG participants have questioned this text in last call for other reasons. Many implementations use anonymous pkinit in a mode where the KDC's certificate is verified--that is the client is anonymous but the KDC is identified through a PKI. WG participants believe (and I agree) that the security concern does not apply at all in this case. So, the text needs reworking. [2] In section 5, the first paragraph in the IANA considerations is unclear, and following its reference to section 4.1, I don't see any clarifying text there either. I think Sections 4.1 and 4.2 need to say that the value of otp-algID is a URI obtained from the PSKC Algorithm URI Registry, and the first paragraph in section 5 should say that URIs for otp-algID are to be registered in that registry, see RFC 6030. Why should we require that alg-ids be registered URIs? I.E. what is wrong with me using http://algorithms.painless-security.com/otp/best-thing-since-unsliced-bread (or a tag URI if you like) for my OTP algorithm? I have no problem with the IETF registering its algorithms there, or us encouraging people to register them them, but it's a URI. What purpose is served by forcing registration? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
Keith Moore wrote: On Aug 24, 2011, at 5:48 PM, Eric Burger wrote: Let's ask again: what is it you WANT? Personally, I want to be able to afford to travel to the meetings, and to be able to do so without having to commit to spending the money months in advance. More broadly, I want IETF meetings to be accessible by a wide range of interests: academics, operators, small vendors, large vendors, even users. Whether or not this is feasible and/or possible by the organization, among the entire thread, this is probably the best ideal to improve the future of the IETF that also takes into account minimizing the expensive total hardship (from travel to lodging) to attend a meeting. There are many aspects of the IETF associated with the desires of different groups that can be distributed into different symposiums, work shops, etc, in different locations. +1. -- Sincerely Hector Santos http://www.santronics.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
I am also a fan of Minneapolis for meetings - the facilities at the Hilton are perfect for our needs. There's lots of food options. It has good air connections and there is decent pubic transport from the airport to the city. However, this seems to be a minority perspective. If we were to do votes again, the results might be interesting. Mary. On Thu, Aug 25, 2011 at 10:55 AM, t.petch daedu...@btconnect.com wrote: - Original Message - From: Thomas Nadeau tnad...@lucidvision.com To: Alia Atlas akat...@gmail.com Cc: Sam Hartman hartmans-i...@mit.edu; Dave CROCKER dcroc...@bbiw.net; ietf@ietf.org Sent: Wednesday, August 24, 2011 10:39 PM On Aug 24, 2011, at 4:33 PM, Alia Atlas wrote: On Wed, Aug 24, 2011 at 4:30 PM, Dave CROCKER dcroc...@bbiw.net wrote: On 8/24/2011 1:27 PM, Sam Hartman wrote: Can you start by backing up the assertion that the community has vigrously expressed a preference for interesting venues? I may just need a new IETF community:-) gosh, I hadn't thought that that was less than obvious, given the vote for quebec and many, many comments about venue choice over the years. I'm one who really liked Minneapolis - we had excellent meeting space, places to run into each other, reasonable food access, and a clueful hotel. Is it interesting to go to new places? Sure and if I'm lucky I might get a morning or afternoon to look around. Would I be perfectly happy going to the same 2-3 places every year? Absolutely. I am with you on that. I do not attend IETFs as a vacation and sight-seeing opportunity. tp Yes, I too go to work, and would rate Minneapolis in the top three, with Atlanta perhaps just above it. Tom /tp --Tom Alia ___ 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: Hyatt Taipei cancellation policy?
On 8/25/11 08:55 , t.petch wrote: Yes, I too go to work, and would rate Minneapolis in the top three, with Atlanta perhaps just above it. Tom /tp --Tom In Minneapolis I think you're talking about a specific venue and city. In the case of Atlanta I'm guessing not, we've had two meetings, 55 and 21. I'm not party to the details for 21 but I helped host 55 and I don't not have a lot of love for the Marriott Marquis. Alia ___ 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: Hyatt Taipei cancellation policy?
If we use actual *attendance* as a form of voting, Minneapolis would lose big time. According to the stats, since IETF-1, there have been 6 IETF meetings in Minneapolis. Every one of them had significantly lower number of participants than the meeting before and after them... except IETF-44 which was lower than IETF-43 but about the same as IETF-45, but IETF-45 was in Oslo, Norway, and IETF-46 went back up to higher levels again. -hadriel On Aug 25, 2011, at 1:12 PM, Mary Barnes wrote: I am also a fan of Minneapolis for meetings - the facilities at the Hilton are perfect for our needs. There's lots of food options. It has good air connections and there is decent pubic transport from the airport to the city. However, this seems to be a minority perspective. If we were to do votes again, the results might be interesting. Mary. On Thu, Aug 25, 2011 at 10:55 AM, t.petch daedu...@btconnect.commailto:daedu...@btconnect.com wrote: - Original Message - From: Thomas Nadeau tnad...@lucidvision.commailto:tnad...@lucidvision.com To: Alia Atlas akat...@gmail.commailto:akat...@gmail.com Cc: Sam Hartman hartmans-i...@mit.edumailto:hartmans-i...@mit.edu; Dave CROCKER dcroc...@bbiw.netmailto:dcroc...@bbiw.net; ietf@ietf.orgmailto:ietf@ietf.org Sent: Wednesday, August 24, 2011 10:39 PM On Aug 24, 2011, at 4:33 PM, Alia Atlas wrote: On Wed, Aug 24, 2011 at 4:30 PM, Dave CROCKER dcroc...@bbiw.netmailto:dcroc...@bbiw.net wrote: On 8/24/2011 1:27 PM, Sam Hartman wrote: Can you start by backing up the assertion that the community has vigrously expressed a preference for interesting venues? I may just need a new IETF community:-) gosh, I hadn't thought that that was less than obvious, given the vote for quebec and many, many comments about venue choice over the years. I'm one who really liked Minneapolis - we had excellent meeting space, places to run into each other, reasonable food access, and a clueful hotel. Is it interesting to go to new places? Sure and if I'm lucky I might get a morning or afternoon to look around. Would I be perfectly happy going to the same 2-3 places every year? Absolutely. I am with you on that. I do not attend IETFs as a vacation and sight-seeing opportunity. tp Yes, I too go to work, and would rate Minneapolis in the top three, with Atlanta perhaps just above it. Tom /tp --Tom Alia ___ Ietf mailing list Ietf@ietf.orgmailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.orgmailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.orgmailto:Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ATT1..c ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On 08/25/2011 09:36 AM, Hadriel Kaplan wrote: According to the stats, since IETF-1, there have been 6 IETF meetings in Minneapolis. Every one of them had significantly lower number of participants than the meeting before and after them... except IETF-44 which was lower than IETF-43 but about the same as IETF-45, but IETF-45 was in Oslo, Norway, and IETF-46 went back up to higher levels again. One could make some guesses about why that might be the case, but probably shouldn't. At any rate I don't think I've ever seen anybody complain about the meeting facilities in Minneapolis. Myself, I think they're probably the best of the various venues we've tried. Must be some other factor. Hm. Melinda ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Questionnaire to survey opinion concerning a possible redefinition of UTC
On 25 August 2011 12:24, Stephane Bortzmeyer wrote: Since several RFCs rely on UTC and leap seconds (3339, 4765, 5905, etc), this questionnaire may be of interest for some persons Thanks for info. MJD 55798.740729 URL:http://tycho.usno.navy.mil/cgi-bin/daterdnm.sh -Frank ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Questionnaire to survey opinion concerning a possible redefinition of UTC
On Thu, Aug 25, 2011 at 1:50 PM, Frank Ellermann hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com wrote: On 25 August 2011 12:24, Stephane Bortzmeyer wrote: Since several RFCs rely on UTC and leap seconds (3339, 4765, 5905, etc), this questionnaire may be of interest for some persons So UTC would become a YATSCOT (Yet another time scale with a constant offset to TAI.) By my count, that would make 4 (not counting time zone offsets). I would contend that RFCs relying on UTC would be unaffected and SHOULD NOT change : - the leap seconds will just stop. Since they are unpredictable, that is really no change. (I.e., the Earth already could chose to rotate in such a fashion as no new leap seconds were ever needed.) That just means little bits of code that won't be executed any more. Not changing the RFCs will future proof you from # 2. - If it is decided in 1000 years to put in a leap hour, that is just so many leap seconds. - UTC would remain civil time (the time computers and networks will mostly be set to, modulo time zone offsets). - I am not aware of any RFCs for sextant based celestial navigation (which WILL have to change). Regards Marshall Thanks for info. MJD 55798.740729 URL:http://tycho.usno.navy.mil/cgi-bin/daterdnm.sh -Frank ___ 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: Hyatt Taipei cancellation policy?
On 25/08/2011 18:12, Mary Barnes wrote: I am also a fan of Minneapolis for meetings - the facilities at the Hilton are perfect for our needs. There's lots of food options. It has good air connections and there is decent pubic transport from the airport to the city. However, this seems to be a minority perspective. If we were to do votes again, the results might be interesting. Mary. I like Minneapolis as well, but then, speaking personally, I like US IETF venues in general. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Hadriel If we use actual *attendance* as a form of voting, Hadriel Minneapolis would lose big time. I don't think using actual attendance is the right metric. Actual attendance of people who submitted internet drafts or chaired meetings would be closer, but is also problematic. My goals are to: 1) Make IETFs easy for people doing current technical work within the organization 2) Ease getting involved in doing technical work in the organization I'm not sure what metric is best for judging things, but I have low confidence that raw attendance maps onto those two goals. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
At 7:06 AM -0400 8/25/11, Keith Moore wrote: (Admittedly, the real gotcha in Quebec seems to have been that there were so few seats available that the few low-priced fares were quickly exhausted. Everyone could get quotes two years in advance and all see the same cheap fares, even if those fares were only available for say 10 seats per day.) I think the small number of carriers and type of service (mostly commuter) had a large effect on Quebec. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- If God lived on Earth, people would knock out all His windows. --Yiddish saying ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: voting system for future venues?
On 8/25/11 11:35 , Randall Gellens wrote: At 7:06 AM -0400 8/25/11, Keith Moore wrote: (Admittedly, the real gotcha in Quebec seems to have been that there were so few seats available that the few low-priced fares were quickly exhausted. Everyone could get quotes two years in advance and all see the same cheap fares, even if those fares were only available for say 10 seats per day.) I used montreal by booking viarail, mechanically it worked rather well but it did take longer. I think the small number of carriers and type of service (mostly commuter) had a large effect on Quebec. Not trying to travel on the same day as the other 600 people trying to get out on friday afternoon is an optimzation of another type. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
At 12:12 PM -0500 8/25/11, Mary Barnes wrote: I am also a fan of Minneapolis for meetings - the facilities at the Hilton are perfect for our needs. There's lots of food options. It has good air connections and there is decent pubic transport from the airport to the city. I fully agree. Minneapolis works well for IETFs. -- Randall Gellens Opinions are personal;facts are suspect;I speak for myself only -- Randomly selected tag: --- wabi (wah-BI; Japanese; noun): a flawed detail that creates an elegant whole. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Hyatt Taipei cancellation policy?
How about Fresno? Sent from my iPhone -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, August 25, 2011 11:09 AM To: ietf@ietf.org Subject: Re: Hyatt Taipei cancellation policy? On 25/08/2011 18:12, Mary Barnes wrote: I am also a fan of Minneapolis for meetings - the facilities at the Hilton are perfect for our needs. There's lots of food options. It has good air connections and there is decent pubic transport from the airport to the city. However, this seems to be a minority perspective. If we were to do votes again, the results might be interesting. Mary. I like Minneapolis as well, but then, speaking personally, I like US IETF venues in general. Stewart ___ 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: Hyatt Taipei cancellation policy?
On 08/25/2011 11:20, John E Drake wrote: How about Fresno? ... just make sure it's upwind from the bovines. :) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Dear sirs, I really appreciate your support to US venues, but please keep in mind, there are places eastern from Bermuda and western from Kauai. In addition there is also some land southern from El Paso. Lets say - Internet is for everyone. And, trust me or not, there are people that have no budget for intercontinental travel and their input is to the community work is valuable too. Sorry for this social two cents in this engineering list. Regards Michal Krsek How about Fresno? Sent from my iPhone -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Stewart Bryant Sent: Thursday, August 25, 2011 11:09 AM To: ietf@ietf.org Subject: Re: Hyatt Taipei cancellation policy? On 25/08/2011 18:12, Mary Barnes wrote: I am also a fan of Minneapolis for meetings - the facilities at the Hilton are perfect for our needs. There's lots of food options. It has good air connections and there is decent pubic transport from the airport to the city. However, this seems to be a minority perspective. If we were to do votes again, the results might be interesting. Mary. I like Minneapolis as well, but then, speaking personally, I like US IETF venues in general. Stewart ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Questionnaire to survey opinion concerning a possibleredefinition of UTC
Marshall Eubanks So UTC would become a YATSCOT (Yet another time scale with a constant offset to TAI.) Indeed, why not use TAI instead in the first place? I am not aware of any RFCs for sextant based celestial navigation (which WILL have to change). If UTC was to change, that could mean some confusion for some sextant users I know who, before using their sextant, check their watch drift against the time provided by, ahem, their GPS receiver. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
Don't worry - this thread occurs on a regular basis, and let's us vent our frustration at having an unsolvable problem. But you do raise a good point about there being places west of Kauai. In fact, my guess is every IETFer is either west or east of Kauai. Therefore, I propose we hold a future meeting on Kauai. The Marriott there can be had for ~$220 in November; and although flights won't be cheap, they will be long so you get a lot more bang for your buck/euro/whatever. The major downside is the sand may be too hot and there is a danger of falling coconuts. -hadriel On Aug 25, 2011, at 4:43 PM, Michal Krsek wrote: Dear sirs, I really appreciate your support to US venues, but please keep in mind, there are places eastern from Bermuda and western from Kauai. In addition there is also some land southern from El Paso. Lets say - Internet is for everyone. And, trust me or not, there are people that have no budget for intercontinental travel and their input is to the community work is valuable too. Sorry for this social two cents in this engineering list. Regards Michal Krsek ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Hyatt Taipei cancellation policy?
On Thu, Aug 25, 2011 at 6:32 PM, Hadriel Kaplan hkap...@acmepacket.comwrote: Don't worry - this thread occurs on a regular basis, and let's us vent our frustration at having an unsolvable problem. But you do raise a good point about there being places west of Kauai. In fact, my guess is every IETFer is either west or east of Kauai. There are a few in South Africa, the antipodes to Kauai, and thus neither East or West (or both, depending on your preference). Therefore, I propose we hold a future meeting on Kauai. The Marriott there can be had for ~$220 in November; and although flights won't be cheap, they will be long so you get a lot more bang for your buck/euro/whatever. The major downside is the sand may be too hot and there is a danger of falling coconuts. Sound good to me. Marshall -hadriel On Aug 25, 2011, at 4:43 PM, Michal Krsek wrote: Dear sirs, I really appreciate your support to US venues, but please keep in mind, there are places eastern from Bermuda and western from Kauai. In addition there is also some land southern from El Paso. Lets say - Internet is for everyone. And, trust me or not, there are people that have no budget for intercontinental travel and their input is to the community work is valuable too. Sorry for this social two cents in this engineering list. Regards Michal Krsek ___ 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: voting system for future venues?
Ole, We can actually arrange for a room block as long as we can guarantee nth number of participants likewise room rates Regards Medel Ramirez Globe Telecom, Inc Manila, Philippines -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ole Jacobsen Sent: Thursday, August 25, 2011 10:33 PM To: Michael Richardson Cc: IETF-Discussion list Subject: Re: voting system for future venues? Michael, I think we could expect a room block cost similar to that of APRICOT 2009, but the dollar has tanked since then so even cheap places in Asia like this aren't so cheap any longer. And, yes, it would be hard go get to for some value of hard. I wasn't proposing we go there. As Nathaniel pointed out, some currencies have really risen against the dollar. It isn't that long ago that the yen was well above 100 to the dollar (the mental calculation point), somewhere in the 110-120 range actually, but TODAY it is at 76-77 yen to the dollar. So, a hotel room back then (the peak was July 2007 at 123 yen to the dollar), say at 15,000 yen would cost ~ $121. Today that same room, still at 15,000 yen will cost ~ $197, heck let's call it $200. The Sing dollar and Oz dollar have done similar things, Canadian too :-) Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Cisco Systems Tel: +1 408-527-8972 Mobile: +1 415-370-4628 E-mail: o...@cisco.com URL: http://www.cisco.com/ipj Skype: organdemo On Thu, 25 Aug 2011, Michael Richardson wrote: Ole == Ole Jacobsen o...@cisco.com writes: Ole The Sofitel Manila is where APRICOT 2009 was held. A great Ole venue, possibly even large enough to hold an IETF (I am not Ole sure), *and* the rate (at the time) at 7,525 Pesos was pretty Ole good. Today it is $177 which is still pretty good. The question Ole is: would the IETF go to the Philippines for a meeting. It's Ole worth finding out. I can't find a flight that gets me there in less than 2 days from Canada. I tried for November. Most transit US (a -0.5 for me), many connect in Tokyo or Hong Kong or Seoul... hmm. travel on Friday is easier than Saturday. The price is about the same as I paid for Prague. The cheapest connects in Guam, which I've always wanted to do. (Of course, the price to Tokyo or Hong Kong or Seoul will be higher..) But, what will the price be, once we get our block? -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[ ] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video http://www.youtube.com/watch?v=kzx1ycLXQSE then sign the petition. ___ 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 This e-mail message (including attachments, if any) is intended for the use of the individual or the entity to whom it is addressed and may contain information that is privileged, proprietary, confidential and exempt from disclosure. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender and delete this E-mail message immediately. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Routing at the Edges of the Internet
I trust that some of you have seen this article from a while back: http://moblog.wiredwings.com/archives/20110315/How-We-Killed-The-Internet-And-Nobody-Noticed.html An informative except: When I open my laptop, I see over ten different wifi access points. Say I wanted to send data to my friend in the flat next to mine. It is idiotic that nowadays, I would use the bottleneck subscriber line to my upstream ISP and my crippled upload speed and push it all the way across their infrastructure to my neighbors ISP and back to the Wifi router in reach of mine. The Internet is not meant to be used that way. Instead, all these wifi networks should be configured to talk to each other. I also trust that you are aware of what happened to the Internet in Egypt (and elsewhere) this spring, where Internet connectivity was disrupted by shutting down major ISP networks. I would like to bring the attention of the IETF to what I see as a fundamental problem with the current architecture of the Internet: The Internet is not a network. As part of the development of the Internet, fault-tolerant routing protocols have been developed that allow a connecdestined fortion to be maintained, even if the link that was carrying goes down, by routing packets around the problem. Similarly, packets can be load-balanced over multiple links for increased bandwidth. However, the benefits of these technologies are not available to end users. If I have a smartphone with both a 3G and a Wi-Fi connection, downloads cannot currently be load-balanced across them. The two interfaces are on two different networks, which are almost certainly part of two different autonomous systems. Packets must be addressed to one of the two interfaces, not the device, and packets addressed to one interface have no way to be routed to the other. Similar problems arise when a laptop has both a wired and a wireless connection. Wired networks also suffer from related difficulties: If I have Verizon and my friend has Comcast, and we string an Ethernet cable between our houses, packets for me will still all come down my connection, and packets for my friend will still all come down theirs. The Internet, as it currently appears to end-users, has a logical tree topology: computers connect to your home router, which connects to your ISP, which connects to the rest of the Internet. Cell phones connect to the tower, which connects through a backhaul link to the rest of the Internet. Almost all of the devices involved have multiple physical interfaces and full IP routing implementations, but only the default route is ever used. This results in a brittle Internet: the failure of one ISP router can disconnect a large number of end-users from the Internet, as well as interrupting communication between those users, even when those users are, physically, only a few feet from each other. My question is this: what IETF work would be needed to add more routing to the edges of the Internet? If each home or mobile device was essentially it's own autonomous system, what would this do to routing table size? To ASN space utilization? How can individuals interconnect home networks when RIRs do not assign address and AS number resources to individuals? How might individuals interconnect home networks without manual routing configuration? Under what circumstances could an ISP trust a client's claim to have a route to another client or to another ISP? How might packets sent to a device's address on one network be routed to that device's address on another network, while packets to immediately adjacent addresses take the normal path? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Questionnaire to survey opinion concerning a possibleredefinition of UTC
On Thu, Aug 25, 2011 at 5:20 PM, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Marshall Eubanks So UTC would become a YATSCOT (Yet another time scale with a constant offset to TAI.) Indeed, why not use TAI instead in the first place? I have asked responsible parties about 2 of these cases (and, for that matter, Dennis McCarthy about UT1) and the answer always is, too much legacy equipment and software. That will sound quaint in 500 years. I am not aware of any RFCs for sextant based celestial navigation (which WILL have to change). If UTC was to change, that could mean some confusion for some sextant users I know who, before using their sextant, check their watch drift against the time provided by, ahem, their GPS receiver. That is the reason for UTC, and the fact that they are getting it from GPS is the reason why no one really cares about keeping UTC close to UT1. Regards Marshall Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Questionnaire to survey opinion concerning a possibleredefinition of UTC
I have asked responsible parties about 2 of these cases (and, for that matter, Dennis McCarthy about UT1) and the answer always is, too much legacy equipment and software. That will sound quaint in 500 years. We're still using the 360-degree circle and the 24 (=12+12) hour day, and those go back to Babylon. But my first thought was, We can't decide on how to decide on a conference location, and people are asking us how to reform the world timing system? Dale ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Questionnaire to survey opinion concerning a possibleredefinition of UTC
On 8/25/11 20:25 , Worley, Dale R (Dale) wrote: I have asked responsible parties about 2 of these cases (and, for that matter, Dennis McCarthy about UT1) and the answer always is, too much legacy equipment and software. That will sound quaint in 500 years. We're still using the 360-degree circle and the 24 (=12+12) hour day, and those go back to Babylon. But my first thought was, We can't decide on how to decide on a conference location, A different slant says we have some moderate trouble deciding on a location (we seem to meet 3 times a year), but that there will always be someone unhappy with the outcome. I think that's more plausibly congruent with what happens with global timing systems. and people are asking us how to reform the world timing system? Dale ___ 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: Agenda known in advance? was Re: Experiment for different schedule for Friday
On 8/23/11 03:25 , Jaap Akkerhuis wrote: If the idea of not fixing agendas is to remain, then any experiments for extending the Friday schedule pretty much mean that everyone has to extend their stay, doesn't it? I think if we want to use Friday time properly, then this ideology needs to go. Fully agree. We should consider Friday (morning) as yet another normal (.5) IETF day or not. The schedule for the last few meetings has in fact done that. not-considering it normal would be a deviation from recent behavior. jaap ___ 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
Weekly posting summary for ietf@ietf.org
Total of 245 messages in the last 7 days. script run at: Fri Aug 26 00:53:02 EDT 2011 Messages | Bytes| Who +--++--+ 0.41% |1 | 14.22% | 319172 | n...@guppylake.com 5.31% | 13 | 4.08% |91519 | o...@cisco.com 2.04% |5 | 4.82% | 108223 | stephen.farr...@cs.tcd.ie 3.27% |8 | 3.37% |75750 | mo...@network-heretics.com 3.67% |9 | 2.75% |61675 | brian.e.carpen...@gmail.com 3.27% |8 | 3.01% |67584 | s...@resistor.net 2.45% |6 | 3.54% |79526 | wesley.geo...@twcable.com 3.27% |8 | 2.32% |52198 | joe...@bogus.com 3.27% |8 | 2.32% |51982 | glenz...@gmail.com 2.45% |6 | 2.52% |56515 | tnad...@lucidvision.com 2.86% |7 | 1.86% |41671 | hartmans-i...@mit.edu 2.45% |6 | 2.09% |46934 | ra...@qualcomm.com 2.04% |5 | 2.30% |51713 | t...@ecs.soton.ac.uk 2.45% |6 | 1.74% |39036 | john-i...@jck.com 1.63% |4 | 2.41% |54205 | acee.lin...@ericsson.com 2.45% |6 | 1.55% |34700 | dwor...@avaya.com 1.63% |4 | 1.71% |38372 | marshall.euba...@gmail.com 2.04% |5 | 1.22% |27425 | hmdmhdfmhdjmzdtjmzdtzktdkzt...@gmail.com 1.63% |4 | 1.09% |24529 | ge...@proto6.com 1.63% |4 | 1.05% |23513 | a...@anvilwalrusden.com 1.63% |4 | 1.04% |23283 | geoff.i...@mulligan.com 1.63% |4 | 1.03% |23015 | melinda.sh...@gmail.com 0.82% |2 | 1.78% |40060 | lmart...@cisco.com 1.22% |3 | 1.23% |27579 | david.bl...@emc.com 1.22% |3 | 1.18% |26568 | me...@globetel.com.ph 1.22% |3 | 1.00% |22535 | nar...@us.ibm.com 1.22% |3 | 1.00% |22458 | daedu...@btconnect.com 1.22% |3 | 0.92% |20652 | f...@cisco.com 1.22% |3 | 0.87% |19594 | rpellet...@isoc.org 1.22% |3 | 0.87% |19469 | d...@dcrocker.net 1.22% |3 | 0.85% |18977 | mstjo...@comcast.net 1.22% |3 | 0.84% |18826 | m...@sandelman.ca 1.22% |3 | 0.79% |17776 | do...@dougbarton.us 0.82% |2 | 1.19% |26740 | jdr...@juniper.net 1.22% |3 | 0.73% |16441 | dcroc...@bbiw.net 1.22% |3 | 0.73% |16327 | stpe...@stpeter.im 0.82% |2 | 0.96% |21475 | mfbe...@gmail.com 0.82% |2 | 0.92% |20759 | venkatf...@gmail.com 0.82% |2 | 0.88% |19847 | hkap...@acmepacket.com 0.82% |2 | 0.76% |16980 | jma...@gmail.com 0.82% |2 | 0.64% |14426 | hsan...@santronics.com 0.82% |2 | 0.64% |14403 | manav.bha...@alcatel-lucent.com 0.82% |2 | 0.64% |14346 | war...@kumari.net 0.82% |2 | 0.57% |12787 | p...@isoc.de 0.82% |2 | 0.56% |12618 | gareth.richa...@rsa.com 0.82% |2 | 0.55% |12415 | d3e...@gmail.com 0.82% |2 | 0.52% |11721 | h...@jpl.nasa.gov 0.82% |2 | 0.52% |11622 | nomcom-ch...@ietf.org 0.82% |2 | 0.51% |11416 | sh...@isc.org 0.82% |2 | 0.50% |11286 | d...@dcrocker.net 0.82% |2 | 0.49% |11006 | ch...@ietf.org 0.82% |2 | 0.44% | 9955 | b...@nostrum.com 0.82% |2 | 0.44% | 9890 | mic...@arneill-py.sacramento.ca.us 0.82% |2 | 0.42% | 9384 | alexey.melni...@isode.com 0.41% |1 | 0.67% |15005 | ron.even@gmail.com 0.41% |1 | 0.57% |12737 | ebur...@standardstrack.com 0.41% |1 | 0.56% |12634 | eburge...@standardstrack.com 0.41% |1 | 0.55% |12369 | mary.ietf.bar...@gmail.com 0.41% |1 | 0.47% |10551 | h...@cs.columbia.edu 0.41% |1 | 0.45% |10039 | presn...@qualcomm.com 0.41% |1 | 0.43% | 9760 | koike.yoshin...@lab.ntt.co.jp 0.41% |1 | 0.41% | 9145 | anshumanpra...@gmail.com 0.41% |1 | 0.39% | 8756 | mach.c...@huawei.com 0.41% |1 | 0.37% | 8293 | c-...@bx.jp.nec.com 0.41% |1 | 0.36% | 8191 | ero...@cisco.com 0.41% |1 | 0.35% | 7925 | interf...@gmail.com 0.41% |1 | 0.35% | 7855 | c.don...@cablelabs.com 0.41% |1 | 0.35% | 7808 | henk.uijterw...@gmail.com 0.41% |1 | 0.34% | 7704 | akat...@gmail.com 0.41% |1 | 0.34% | 7689 | lber...@labn.net 0.41% |1 | 0.33% | 7425 | h...@uijterwaal.nl 0.41% |1 | 0.32% | 7228 | kathleen.moria...@emc.com 0.41% |1 | 0.32% | 7149 | bortzme...@nic.fr 0.41% |1 | 0.31% | 7031 | christer.holmb...@ericsson.com 0.41% |1 | 0.31% | 6913 | ghud...@mit.edu 0.41% |1 | 0.31% | 6898 | tglas...@certichron.com 0.41% |1 | 0.31% | 6859 | st...@shinkuro.com 0.41% |1 | 0.30% | 6803 | mic...@krsek.cz 0.41% |1 | 0.30% | 6700 | ned+i...@mauve.mrochek.com 0.41% |1 | 0.29% | 6536 | d...@xpasc.com 0.41% |1 | 0.29% | 6408 | stbry...@cisco.com 0.41% |1 | 0.28% | 6330 | chris.new...@oracle.com 0.41% |
Re: Manila, was voting system for future venues?
I can't find a flight that gets me there in less than 2 days from Canada. I tried for November. Um, you can fly YYZ-NRT/NRT-MNL on AC and NH in about 20 hrs. The return flight is about 18 hrs, same route. Any chance we've forgotten about the International Date Line? I see coach fares of about $1200 which is not bad for such a long trip. From YOW, it's not surprisingly 2-3 hrs more with another connection, but there's a reasonable route on DL via Detroit and Nagoya for only $917, 22 hrs out, 21 hrs back. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RFC 6339 on Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API)
A new Request for Comments is now available in online RFC libraries. RFC 6339 Title: Context Token Encapsulate/Decapsulate and OID Comparison Functions for the Generic Security Service Application Program Interface (GSS-API) Author: S. Josefsson, L. Hornquist Astrand Status: Standards Track Stream: IETF Date: August 2011 Mailbox:si...@josefsson.org, l...@apple.com Pages: 8 Characters: 13285 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-josefsson-gss-capsulate-05.txt URL:http://www.rfc-editor.org/rfc/rfc6339.txt This document describes three abstract Generic Security Service Application Program Interface (GSS-API) interfaces used to encapsulate/decapsulate context tokens and compare OIDs. This document also specifies C bindings for the abstract interfaces. [STANDARDS-TRACK] 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 6361 on PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol
A new Request for Comments is now available in online RFC libraries. RFC 6361 Title: PPP Transparent Interconnection of Lots of Links (TRILL) Protocol Control Protocol Author: J. Carlson, D. Eastlake 3rd Status: Standards Track Stream: IETF Date: August 2011 Mailbox:carls...@workingcode.com, d3e...@gmail.com Pages: 8 Characters: 17705 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pppext-trill-protocol-08.txt URL:http://www.rfc-editor.org/rfc/rfc6361.txt The Point-to-Point Protocol (PPP) defines a Link Control Protocol (LCP) and a method for negotiating the use of multiprotocol traffic over point-to-point links. This document describes PPP support for the Transparent Interconnection of Lots of Links (TRILL) Protocol, allowing direct communication between Routing Bridges (RBridges) via PPP links. [STANDARDS-TRACK] 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
