RE: I-D submission tool
John C Klensin wrote: > For the second, it claims that the file isn't "plain text" and > won't post it or even provide a manual submission path. The > file is output or xml2rfc, has proper CRLF line endings, and, if > it contains any non-ASCII characters or serious format > misbehavior, the online version of idnits can't find it, even in > very verbose mode. [rt.amsl.com #1799] I also encountered this problem (rt.amsl.com #1730), and after some debugging, discovered what the problem was: the submission tool uses the "file" program to check whether the file is plain text or not, and (apparently) the "file" program on the new servers behaves slightly differently from the old one. In particular, if you have the string "(if approved)" on your cover page, some versions of "file" (at least some Linux distributions) will identify your draft as "Lisp/Scheme program text" instead of just ASCII :-) Best regards, Pasi ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
David Kessens wrote: > PS anyways, maybe the local/Dublin restaurant scene is really not what we >should be looking for in Ireland: should we not care more >about the local brews ? Open taps in each meeting room might, indeed, eliminate any complaints about the venue. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Thanks for your quick response, comments inline: > -Original Message- > From: Lakshminath Dondeti [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 06, 2008 1:03 AM > To: Joseph Salowey (jsalowey) > Cc: [EMAIL PROTECTED]; ietf@ietf.org > Subject: Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP > Extensions for EAP Re-authentication Protocol (ERP)) to > Proposed Standard > > Thanks for the review Joe. > > On 2/5/2008 11:26 PM, Joseph Salowey (jsalowey) wrote: > > In reading this draft (-09 version) I came up with a few > questions and > > comments: > > > > Section 3 - > > > > Section 3 is a bit confusing it seems that much of the text > is section > > 3.1 (detailed description of exchanges) should go into section 3.0 > > because it seems that much of the process should be the > same for local > > or remote cases. Currently it is difficult to really tell what > > pertains to local, remote and both. > > > > It does not appear to be clear how the peer knows if it is > in the "home" > > case or the "local" case, whether the network is capable of > ERX (and > > vice versa) or how the peer knows what key to use. Perhaps > I missed > > this elsewhere in the document. > > We worked to clarify this in the last revision. I will make > another pass at it while preparing v10 and run it by you > (probably sometime tomorrow). > > > > > Section 4 - > > > > Section 4.1.1 duplicates text in > > internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt. It really > > should not. It should reference KDF functions instead of PRFs. I > > believe if you replace prf+ with KDF it would be fine. Do > you want to > > use the naming defined in > > internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt or are you > > specifying your own? Are these key names really necessary? > They do > > no appear to be used anywhere? > > This is true. I think we were trying overly hard to name > everything (one of 4962 things?) and I realized earlier that > we have a procedure to even name the rMSKs. But, it is not > clear whether the rMSK names will be used anywhere. > > I just sent that email about naming and so we should be able > to clean this stuff up now if that is acceptable to everyone. > [Joe] If this is what we discussed I believe it will help, I will take a look at that. > On duplication, it seems we have two strong opinions here. > You are suggesting less duplication and Alan is suggesting > more :). I guess we may have actually achieved the (un)happy medium! > > My opinion is that we should have less duplication, perhaps > to the extent you are suggesting, so the idea is to not have > to update (when we > need) text in two different drafts. That said, there are > some usage specific properties to consider, specifically we > are trying to specify crypto-agility in case of ERP and for > those reasons, the derivations may need to be spelled out again. > [Joe] I think if we need to spell out the derivations in this document there is a problem. This would indicate there is something wrong with the EMSK document that needs to be fixed. > In the next revision, I'll see what I can do to reduce the > duplication (but before that I will talk to Alan to see what > he wants). > > > > > Why such a long key label? > > Which one? > "EAP Re-authentication Root [EMAIL PROTECTED]"? I guess we could > call it "EAP rRK" but that might be an abbreviation for > something else in the future. Please suggest another name > :), but hopefully one that does not involve changing the > entire document (I don't want to introduce errors with too > many global changes). > [Joe] I suppose it doesn't matter much, it just seems that name is unnecessarily long. The point of registering the labels with IANA is to avoid conflicts. > > > > Section 5 - > > > > Section 5.1 > > > > What state are you referencing here? I don't think the > > CalledStation-ID is what you want to reference, I believe RADIUS > > routing is typically done with the username when EAP is > used. Why is > > it only RECOMMENDED to maintain this state? It seems > either it is a MUST or it doesn't matter. > > In general authenticators do not do routing, AAA does routing. > > Authenticators copy the correct attributes from EAP into > the correct > > attributes in the AAA message. This seems much more complicated > > (routing, multiple attributes TLVs etc). Its not clear if the 3 > > sub-bullets of the first bullet refer to what the > authenticator needs to > > do or the peer needs to do. It seems that the > authenticator should be > > able to extract a single field from the peer message to > determine what > > to do with it. Either it will handle it locally or it will > pass the > > message within the AAA protocol copying the appropriate > field into the > > message. > > I see. I will make it clear and separate as to what the peer > must and what the authenticator must do. I think we h
Re: IETF 72 --> Dublin!
Richard, On Wed, Feb 06, 2008 at 10:41:07PM -0500, Richard Shockey wrote: > My comment said "or" as in one or the other, if you had re read the comment > properly before going snarky. I don't dispute Dublin airport is a useful > transportation hub. I want to know why this particular venue was selected > and what was the criterion used to make the evaluation. That is a simple > question given the legitimate questions many of us are asking. By mentioning 'major hub' it appeared as if you were concerned about that as well while in fact this location is an excellant choice from that perspective: not only is it easy to get to, but it is also comparatively cheap for many IETF participants. > IMHO it was a bad selection and I think many of us want to make sure it does > NOT happen again. that really remains to be seen: as many people have mentioned before, there might actually be some reasonible local food options. In addition, with a little planning, it should be possible for many of us to go once or twice to Dublin itself or perhaps stay a day extra. I admit, not 100% ideal but meetings always have their tradeoffs. In this case, I certainly see the potential for problems, but on the other hand, if the connectivity is particularly good, the hotel rooms a bit better than average and the local restaurant situation a tiny bit better than what many people expect, one can hardly claim that this meeting is going to be a disaster. Let's first go there before we make a judgement that this was a terrible mistake, the data so far simply doesn't justify that (yet ;-)). David Kessens PS anyways, maybe the local/Dublin restaurant scene is really not what we should be looking for in Ireland: should we not care more about the local brews ? --- ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
100% agree with all your points. I think we should focus on if the IONs are needed. If we determine they are, then we can discuss things we learned about the tooling and how to do it better. Cullen On Feb 6, 2008, at 6:34 PM, Harald Alvestrand wrote: > > - that one should be able to tell who approved it, and when > - that one should be able to tell the difference between a final > document and a draft. > > > I think we need to continue to have both of these properties. > > There's no requirement that a process exist for handling them, or even > that it be consistent between IONs. The existing process is, > deliberately, unconstrained by the RFC. > > I could argue that we might need fewer tools, not more; any tool you > create increases the number of tools one has to learn in order to get > one's job done. But that's part of what the experiment has been about. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
> The descriptions of the venue make clear that, once again, the IETF > is meeting in a ghetto. Periodic bus service doesn't counteract > that. If you look at the Google map and satellite photos of the venue, there appears to be quite a lot of residential and commercial development just east of it. Perhaps someone who lives in Dublin could let us know if there are useful facilities there. Poking around in Google, I see the Citywest Comfort Inn is 3.7km east with rooms from E79 and the Tower Hotel Dublin is 5.7km east with rooms from E99, not walkable but reasonable for shared taxis. There also seem to be several hotels in Tallaght, about 10km away. I agree that it is not practical to commute very far by road around Dublin, since the roads tend to be narrow and congested. R's, John ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: IETF 72 --> Dublin!
My comment said "or" as in one or the other, if you had re read the comment properly before going snarky. I don't dispute Dublin airport is a useful transportation hub. I want to know why this particular venue was selected and what was the criterion used to make the evaluation. That is a simple question given the legitimate questions many of us are asking. IMHO it was a bad selection and I think many of us want to make sure it does NOT happen again. That said I love Ireland .. delighted to go there ..but. > -Original Message- > From: David Kessens [mailto:[EMAIL PROTECTED] > Sent: Wednesday, February 06, 2008 5:21 PM > To: Richard Shockey > Cc: 'IAB'; 'IETF Discussion'; 'IAOC' > Subject: Re: IETF 72 --> Dublin! > > > Richard, > > On Wed, Feb 06, 2008 at 04:48:15PM -0500, Richard Shockey wrote: > > > > Sites that are substantially distant from city centers or major > > transportation hubs IMHO don't work for the IETF community > irrespective of > > whether they are in North America, Asia or ECMA. > > While I don't particularly like this location, I don't see how you can > imply that it is hard to get to Dublin airport and from there to the > meeting site. Aer Lingus has reasonably priced (for summer time) > direct flights from most large US cities. Most european cities are > served by Aer Lingus and by Ryan Air which is quite possible the > cheapest airline on earth. > > David Kessens > --- ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: Call for Comment: RFC 4693 experiment
Cullen Jennings skrev: > > I'd like to comment as an individual on one part of our process for > doing IONs. > > The process for publishing them has many bottlenecks and delays and we > need a better way of doing it. If we decide to continue with IONs, I > will provide detailed comments on issues with how we are doing them. > Overall I think we would need tools so that an ION author can put a > new version, reviewers could easily see the diffs from the previous > version, and when the document is approved by the approving body, it > gets posted and does not require manual editing of the document after > it was approved. one comment... the procedure as described in the ION RFC has exactly two requirements: - that one should be able to tell who approved it, and when - that one should be able to tell the difference between a final document and a draft. I think we need to continue to have both of these properties. There's no requirement that a process exist for handling them, or even that it be consistent between IONs. The existing process is, deliberately, unconstrained by the RFC. I could argue that we might need fewer tools, not more; any tool you create increases the number of tools one has to learn in order to get one's job done. But that's part of what the experiment has been about. Harald ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
I-D submission tool
Just as a heads-up, this tool seems to have gotten at least partially broken. I have submitted trouble tickets to ietf-action, but to save others from wasting time trying to get around the problems (and in the hope that someone will have an idea as to a workaround)... In the last two hours, I've tried to submit two drafts. For the first, it claimed it couldn't find Author address metadata. After some fussing around and experimenting, it turns out that having the string " (editor)" after the Author's name -- a format that xml2rfc produces in response to a 'role="editor"' parameter and that has been in use in RFCs for more years than I can remember-- it gets too confused to believe that there is author information present. [rt.amsl.com #1796] if anyone is interested. For the second, it claims that the file isn't "plain text" and won't post it or even provide a manual submission path. The file is output or xml2rfc, has proper CRLF line endings, and, if it contains any non-ASCII characters or serious format misbehavior, the online version of idnits can't find it, even in very verbose mode. [rt.amsl.com #1799] I can only hope these sorts of little problems can be fixed before the posting deadlines for the next IETF get any closer. And, if not, that there is adequate staff to do a lot of manual posting. john ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
O&M Directorate Review of draft-ietf-hokey-erx-09
Review of draft-ietf-hokey-erx-09 I have reviewed this document as part of the Operations and Management directorate effort. These comments were primarily written for the benefit of the O&M area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Detailed review comments are available here: http://www.drizzle.com/~aboba/EAP/erx-review.txt An answer to typical O&M issues is included below: 1. Is the specification complete? Can multiple interoperable implementations be built based on the specification? There are a few areas of the document which are unclear to me, such as how AAA routing is accomplished, and how/when peers require the local realm, and if so, how it is to be obtained. Also, clarity with respect to algorithm agility could be improved. There are also some issues with respect to the required behavior of ERX peers and severs (use of normative language). There are also situations in which multiple approaches can be chosen (such as the various bootstrap options), without one being chosen as mandatory or default. Choosing one approach would seem to be better. In my judgement, addressing these issues would improve the likelihood of being able to build multiple interoperable implementations. 2. Is the proposed specification deployable? If not, how could it be improved? Based on my reading of the document, it would appear that the ERX proposal requires changes to EAP peers, authenticators and servers, as well as RADIUS clients, proxies and servers. It also appears possible that changes to the lower layer protocols will be required in at least some cases, such as to make the local domain available to the peer. Given my experience in designing and operating wireless networks, deployments requiring changes only to peers and authenticators (but not servers or RADIUS infrastructure) can take as long as 3-5 years to complete. For example, WPA2 is still not universally deployed, even though the specification was finished in 2004. By also requiring changes to AAA infrastructure, it seems to me that ERP deployment will be made more difficult than upgrades to the lower layer (such as IEEE 802.11r), which appear to achieve a similar objective. This puts the ERX proposal at a competitive disadvantage, and makes it unlikely that it will be widely deployed in its current form. 3. Does the proposed approach have any scaling issues that could affect usability for large scale operation? The proposed approach introduces state into NASes, as well as RADIUS proxies and servers. This state is typically of two types: routing state and key state. In terms of key state storage, it would appear that the RADIUS server needs to store key state for each authenticated user within the Session-Id lifetime, regardless of where they are located. Local ERX servers store state for all local users, regardless of their home realms. In order to scale to handle a large user population, additional RADIUS servers are typically deployed, going against a replicated backend store (such as an LDAP directory). Similarly, additional RADIUS proxies are deployed to handle the forwarding load. In conventional RADIUS deployments, proxies act much like routers, so that the failure of a RADIUS proxy will not necessarily result in failure of an EAP authentication in progress. For example, a NAS could switch over from use of one proxy to another one and as long as the same RADIUS server remained reachable, the conversation could complete normally. Similarly, while failure of a RADIUS server during a conversation will require re-starting the EAP conversation, that conversation could complete normally if restrated with a new server, since all servers presumably have access to the same backend credential store. Some of these assumptions no longer apply with ERX, since RADIUS proxies and servers now store key state which is not replicated between them. Therefore RADIUS failover would disrupt the functioning of ERX in a way that it does not disrupt operation of RADIUS today. For example, if a RADIUS proxy or server goes down, all key state at that proxy/server may be lost (the document does not talk about use of stable storage to preserve keys), and therefore ERP requests will fail. With respect to the resource requirements required to store key state, I believe that they are manageable for the most part. Typically RADIUS servers have substantial resources associated with them, so that they are more capable of handling this kind of state than NASes which are embedded devices. In terms of NAS state, it would appear to me that the proposed approach scales better than existing proposals such as IEEE 802.11r, since an authenticator will only hold state for connected devices, as opposed to devices that *might* connect in the future. My only concern would be about RADIUS proxies. In my experience, proxies are often installed in co-location
Re: IPv6-clean path from root to www.ietf.org?
On 5-Feb-2008, at 23:48, Ram Mohan wrote: > This will get taken care of in a short time here. Appropriate records were added to the INFO zone earlier today. Joe ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
David Kessens wrote: > Maybe you should volunteer for a position on the IAOC if you believe > you can set these priorities better than the people who are > currently responsible for this job. David, Maybe a discussion about priorities should be a discussion about priorities rather than being treated as some sort of attack? Or is the current IETF culture such that a participant is considered hostile merely by their asking such a question? > Quite frankly, I am not looking forward for a resort hotel setting in > the proximity of Dublin as opposed to for example a meeting in Paris. > However, that is just based on personal preferences that don't really > disqualify this location as a good location for a productive meeting > (we don't even know whether there are not a decent number of > restaurants etc. nearby the venue). Actually, I believe that has already been discussed. Please note that I didn't send my query until after the local logistical details of the venue were discussed at length. d/ ps. Please also note that my original query was simply about the ranking of considerations and that, so far, no IETF management folk have responded to that focus. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
David Kessens wrote: > Most european cities are served by Aer Lingus and by Ryan > Air which is quite possible the cheapest airline on earth. Only because I happened to see this today: > Airline ordered to pay for booting band The Associated Press Article > Launched: 02/06/2008 07:08:27 AM PST > > LONDON—A British judge has ordered budget airline Ryanair to pay $7,800 to > members of a calypso band who were ordered off a plane at gunpoint after > another passenger said they were acting suspiciously. > > Ryanair said it had not decided whether to appeal the ruling. > > Five members of the London-based Caribbean Steel International band were > aboard a flight waiting to fly from the island of Sardinia to London on Dec. > 31, 2006, when a passenger alerted the crew of "suspicious" behavior. > > The band members were sitting separately on the plane, even though they had > been together in the departure lounge, the passenger reported. > > The men were removed from the plane by Italian police with guns drawn, though > they were later cleared by airport security. The pilot refused to let them > back onboard, citing the "anxiety" of the other passengers. > > District Judge Roger Southcombe ruled Tuesday that the men had been > unreasonably removed from the plane. He awarded them $1,570 each in damages. > > In the judgment, Southcombe said the damages awarded reflected the band > members' "embarrassment at being the only black persons removed from the > aircraft at gunpoint for no just reason, their inability to be with their > families and friends on New Year's Eve and New Year's Day (and) the overnight > stay in the cold in Liverpool." > > The men were flown to Liverpool and spent the night of Jan. 1 outside the bus > station after missing the last bus to London. -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Jaap Akkerhuis wrote: [..] And it seems the the resort is build on the meadows used by the fairies. Fairies hebben geen heibel gemaakt want de golf-velden daar liggen er super mooi bij. Er is ook een helicopter landplaats daar, wat wellicht een goede optie is :) I'm afraid that the potheen will be less available then it used to be. That's progress I assume. What makes me think the public transport might have improved although the traffic jams might be a new problem. That's progress again. Maybe can rent a bike. Een ding wat je dus NIET wilt doen is fietsen in Dublin. Het gaat best op zich hoor, maar je moet wel heel erg oppassen en het liefste over de stoep fietsen. Vooral bussen en taxis hebben namelijk nogal de rare neiging om fietsers gewoon maar de kant (lees: muur, paal, andere autos) in te drukken. Ik heb er een jaartje gewoont en veel gefietst, want dat openbaar vervoer is NIETS, nog erger dan de NS in nederland (al is de trein redelijk de paar keer dat ik hem gebruikt heb): ze hebben geen echt schema voor de bussen, er komen er dus gerust twee achter elkaar en dan heel lang niets, als je je hand niet opsteekt stoppen ze niet. Ze vergeten te stoppen, ook al druk je tig keer op de knop of zeg je het tegen de chauffeur dat ie hem toch echt gemist heeft etc. Oh en dan natuurlijk het verkeer, muur vast want de straten zijn te smal en de bussen passen er eigenlijk niet door heen, daarnaast stopt er een, en de andere erachter moet dan maar wachten, etc, etc. Ramp dus, dus pak je als nederlander lekker de fiets. Aanrader, koop schoenen zoals ik heb: http://www.underground-cybershop.co.uk/acatalog/info_UR_044_L_BLK.html Juist ja, zware schoenen met mooie keiharde plastic neuzen en een tikkel metaal zodat, als er weer een bus over je tenen rijdt omdat die het leuk vind om je de kant in te forceren je iig geen platte tenen overhoudt, nee idd deze schoenen deuken niet :) Platte land, dus in de buurt van dat hotel is het overigens goed te doen hoor, want je zit er effectief in de middle of nowhere, maar *in* Dublin, probeer de fiets maar niet, taxi is een halve optie, de andere manier is de tram nemen, die dan nog half-redelijk rijd. Enne, vergeet de paraplu niet, want die ga je nodig hebben ;) Greets, Jeroen signature.asc Description: OpenPGP digital signature ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Richard, On Wed, Feb 06, 2008 at 04:48:15PM -0500, Richard Shockey wrote: > > Sites that are substantially distant from city centers or major > transportation hubs IMHO don't work for the IETF community irrespective of > whether they are in North America, Asia or ECMA. While I don't particularly like this location, I don't see how you can imply that it is hard to get to Dublin airport and from there to the meeting site. Aer Lingus has reasonably priced (for summer time) direct flights from most large US cities. Most european cities are served by Aer Lingus and by Ryan Air which is quite possible the cheapest airline on earth. David Kessens --- ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Dave, On Wed, Feb 06, 2008 at 11:54:43AM -0800, Dave Crocker wrote: > > Hence the question about priorities. Start with declaring Dublin the venue > and > it well might be true that this is the best venue. Start with a requirement > that the venue have ample resources within walking distance and Dublin well > might be disqualitied. > > It's all about priorities. > > And no, I would not have queried if I hadn't felt that attendee convenience > were > not the priority that should be highest, but that it appears not to have been > for the Dublin event. Maybe you should volunteer for a position on the IAOC if you believe you can set these priorities better than the people who are currently responsible for this job. Quite frankly, I am not looking forward for a resort hotel setting in the proximity of Dublin as opposed to for example a meeting in Paris. However, that is just based on personal preferences that don't really disqualify this location as a good location for a productive meeting (we don't even know whether there are not a decent number of restaurants etc. nearby the venue). On the other hand, considering the origin of Alcatel-Lucent, I have my suspicions that Paris actually has been considered and didn't work out for other reasons. I am sure Ray can give us a bit more background why we ended up in this venue (and why my corporate rate was quite a bit more attractive than the IETF rate ... ) David Kessens --- ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
BTW - I have no knowledge of the venue, I've never been to Ireland. I'm reacting to seeing these complaints pile up over the years about nearly everywhere we have been. I remember staying in Rathcoole about 35 years ago. It was a lovely rural place. I came back to stay there again. There was at time a doable bus service to Dublin. Apparently the place has changed a lot since that time. Looking to the google maps provided by the home page of the resort, the runway for the small airfield against which people were opposing because it would disturb the little people got build in the end. And it seems the the resort is build on the meadows used by the fairies. I'm afraid that the potheen will be less available then it used to be. That's progress I assume. What makes me think the public transport might have improved although the traffic jams might be a new problem. That's progress again. Maybe can rent a bike. Anyway, it will be fun to go back there. jaap ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Dan York wrote: > While I agree with the sentiments of Ted and others[1], isn't this all > rather a moot point? > I would expect Ray has already signed a locked-in contract with the > hotel/resort in Dublin, correct? > Is there realistically any chance to change it? So it's probably a good thing that my query made no mention of trying to change the Dublin arrangements. I asked about decision criteria, in the hope that they can be improved. This isn't about changing Dublin, criticizing anyone, or doing anything more than improving the ranking of criteria. Every time the IETF venue is isolated, it is a logistical problem during the week. Yet that fact seems to be getting ignored -- or rather, ranked lower than other priorities. From my own view, the IETF venue should encourage attendance and interaction. Attendance is affected by convenience of access and cost. Access to less expensive hotels *that are as convenient as the primary hotel* is significant to this end. Interaction is affected by the ability to break into casual small group discussions. Having a sterile or monotonous or expensive environment works against this. Having access to a variety of convenient, alternative places works in favor of it. For those who don't care about being locked into an isolated venue, they won't mind having the IETF held among a small set of venues that do have good local logistics. They exist in various places around the world. Choose a small set and rotate among them. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
RE: IETF 72 --> Dublin!
> > It's Ray's job to make the call. It's the IAOC's job to see that he > does his job well. I think Ray has at least earned the benefit of the > doubt. I don't think so ..given the perfectly rational questions that are being asked about this particular sub-optimal site, the community has a perfect right to ask pointed questions about why it was selected and what if any were the alternatives. The deal is done, I agree with that, but there are aspects of this particular selection that are different from any other I've seen in the IETF in the 10 years or so I've been attending. Sites that are substantially distant from city centers or major transportation hubs IMHO don't work for the IETF community irrespective of whether they are in North America, Asia or ECMA. Perhaps this is best viewed retrospectively since contracts > are signed? > > Eliot ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
On 6 feb 2008, at 21:53, Eliot Lear wrote: >> I sometimes wonder how cheap and convenient IETF meetings would be >> if the fee reflected just the meeting costs, the hotel room fees >> wouldn't be used to subsidize the venue price and venue selection >> only considered price and convenience for the IETF goers and not a >> host. > Those aren't the only criteria. Try finding a place in Europe that > can fit our plenary and ALSO house the number of WG meetings we > have. That ain't easy. Well, a few years I thought I had found just such a place: a convention center with 500 hotel rooms within five minutes walking distance and many more a little further away. However, even simple questions as to how many hotel rooms were required these days were never answered. Comments from others who spent considerable effort trying to find a European location for an IETF meeting tell me there was significant room for improvement in the venue selection process some years ago. I hope this improvement has since happened. > It's Ray's job to make the call. It's the IAOC's job to see that he > does his job well. I think Ray has at least earned the benefit of > the doubt. Perhaps this is best viewed retrospectively since > contracts are signed? I think the most helpful approach at this point is to find hotels and restaurants close to the venue for those of us who don't want to be in the meeting hotel for 4.5 days straight, and then see what transportation options are available. I remember much shorter bus trips in Dublin taking a long time: the streets are narrow and can be busy. Commuting from the city center is probably not a reasonable option. Maybe Ray can arrange for IETF'ers on a budget to pitch tents on the edge of the golf course and forage from the surrounding country. :-) I did this in 2005 in the Irish countryside (well, maybe not the foraging part) and it was a lot of fun: http://www.flickr.com/photos/technokitten/sets/1393969/ ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
I wrote: > > It's Ray's job to make the call. It's the IAOC's job to see that he > does his job well. I think Ray has at least earned the benefit of the > doubt. Perhaps this is best viewed retrospectively since contracts > are signed? I am told the following by someone who should know: > Actually, Ray really does NOT make these decisions in the absence of > much debate and analysis within the IAOC and its various committees. Eliot ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Iljitsch van Beijnum wrote: > I sometimes wonder how cheap and convenient IETF meetings would be if > the fee reflected just the meeting costs, the hotel room fees wouldn't > be used to subsidize the venue price and venue selection only > considered price and convenience for the IETF goers and not a host. > Those aren't the only criteria. Try finding a place in Europe that can fit our plenary and ALSO house the number of WG meetings we have. That ain't easy. I've said this privately and I guess I'll say it publicly. I'm no fan of CityWest. But... It's Ray's job to make the call. It's the IAOC's job to see that he does his job well. I think Ray has at least earned the benefit of the doubt. Perhaps this is best viewed retrospectively since contracts are signed? Eliot ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
On 6 feb 2008, at 17:57, Ole Jacobsen wrote: > 1. IETF meetings require BOTH a suitable venue (meeting rooms) AND a > host organization. I sometimes wonder how cheap and convenient IETF meetings would be if the fee reflected just the meeting costs, the hotel room fees wouldn't be used to subsidize the venue price and venue selection only considered price and convenience for the IETF goers and not a host. Too bad the IETF hasn't been able to figure out a different business model. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
While I agree with the sentiments of Ted and others[1], isn't this all rather a moot point? I would expect Ray has already signed a locked-in contract with the hotel/resort in Dublin, correct? Is there realistically any chance to change it? If the Dublin venue can NOT be changed at this point, should we perhaps focus on how we can get to restaurants? Can we get more shuttles? Is there taxi service available? etc.? My 2 cents, Dan [1] Like Ted, I go to a standards meeting to engage in f-2-f discussions. If there is any "sightseeing" it is usually in my walk from my hotel to the conf center or perhaps at the social event. All I really ask for is a decent hotel room, good meeting rooms, decent snacks, hot tea, good WiFi and easy access to multiple restaurants so that when 1,000+ standards geeks all break at the same time for lunch or dinner we're not all standing in line at the same restaurant trying to get served quickly so we can go back into our meetings. IETF 70 in Vancouver and IETF66 in Montreal were both great examples to me where there were plenty of choices within easy walking distance. On Feb 6, 2008, at 2:27 PM, Theodore Tso wrote: For me, I'll take business-class hotel like a Hilton or a Doubletree any day and even better if it is adjacent to a mall with a food court. When I go to an conference or a standards meeting, it's to get work done, not to do fine dining or lounge at a resort setting. And if I'm going to pay $$$ for an expensive restaurant, I want to get my money's worth, which is rarely the case at most hotel restaurants. - Ted [1] http://thunk.org/tytso/blog/2007/10/08/sous-vide-revisited/ ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: [IAOC] IETF 72 --> Dublin!
Dave, (Reducing the CCs a bit) On Wed, 6 Feb 2008, Dave Crocker wrote: > Ole Jacobsen wrote: > > Dave, > > > > Not wishing to speak for Ray, let me give some general observations: > > > > 1. IETF meetings require BOTH a suitable venue (meeting rooms) AND a > >host organization. > > Sorry, but it has been demonstrated that a host is not required. > > It has further been demonstrated that the host (or, rather, the sponsor) does > not have to be co-resident with venue. "Has been demonstrated" does not mean that this is always possible. And yes, I meant SPONSOR rather than host in the classic sense. We have indeed had hostless meetings, but a number of factors have to come together to make this work. > > > > 2. The host organization have a large say in location (city) > >selection, for a number of reasons. We are going to Philadelphia > >because that is where the HQ of our host is located, for example. > > This has been the classic model, yes, but recently has been > considerably loosened. Sure, but again, this depends on the host/sponsor. We cannot always dictate these things --- unless of course we find a completely DIFFERENT funding model, but that's outside the scope of this particular discussion. > > > > 3. While "isolated" venues may be "problematic", there is always a > >tradeoff between a suitable venue (again meeting rooms) and its > >distance to nearby hotels and other facilities. In the case of > >Dublin, it is anticipated that most attendees will stay in the > >main hotel. Having only been party to some of the discussions > >around this particular venue I can only say that CityWest was > >considered to be by far the best alternative --- in Dublin. > > Hence the question about priorities. Start with declaring Dublin the venue > and > it well might be true that this is the best venue. Start with a requirement > that the venue have ample resources within walking distance and Dublin well > might be disqualitied. It was decided that "Europe" was in the rotation cycle this time around. CityWest has, from what I understand, a number of bars and restaurants which will serve us well during the meeting. There will be shuttle buses (a la Dallas) for the evening. If you found the Dallas venue to be completely unacceptable (flooding nothwithstanding), then I'm afraid you'll probably hate CityWest too. Personally I found Dallas to be just fine. > > It's all about priorities. > > And no, I would not have queried if I hadn't felt that attendee convenience > were > not the priority that should be highest, but that it appears not to have been > for the Dublin event. Attendee convienience is a concept we could debate. Having the majority of the hotel rooms close to the meeting rooms is high on my list at least. > > d/ Ole ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
I am still not convinced that there is a shortage of other places for lunch. Citywest (that the hotel is part of) http://www.citywest.ie/ is a large business campus (including some companies that will be familiar to IETF participants) In their list of amenities it says that there is "a choice of restaurants and coffee shops" within the complex and nearby. As there would have to be to support a large white collar employee base.. And I found several well reviewed lunchtime restaurants (including a food hall with well reviewed "takeaway") in Saggart and Rathcoole. e.g., http://www.menupages.ie/Dublin/Restaurants/Saggart http://www.menupages.ie/Dublin/Restaurants/Rathcoole and a little further away http://www.menupages.ie/Dublin/Restaurants/Newcastle http://www.menupages.ie/Dublin/Restaurants/Lucan Personally, I am not worried about finding places for lunch outside the hotel. Janet The resort may be "self contained", but it appears to be by no means "isolated". Janet [EMAIL PROTECTED] wrote on 02/06/2008 02:29:43 PM: > > Hi Edward, > > On Wed, February 6, 2008 10:29 am, Edward Lewis wrote: > > At 8:37 -0800 2/6/08, $someone wrote: > > > >>The descriptions of the venue make clear that, once again, the IETF is > >> meeting > >>in a ghetto. Periodic bus service doesn't counteract that. > > > > I really have a hard time being sympathetic to this complaint. If > > the purpose of the IETF is open discussion and cross-pollination, > > what does it matter where we are so long as there's comfortable > > access to the expertise needed? Is there an unwritten requirement > > that IETFs are placed to afford us sightseeing? To afford us access > > to restaurants? > > Think about why a beer in a bar in a city center costs 1/4 the price > of a beer in the airport of that same city-- captive audience, it's not > like you can go anywhere else. > > Now, this IETF is at a premier golf resort, 15km outside of city > center. That means we'll be a captive audience and we will all eat at > the hotel restaurant day in and day out and most likely pay far more > than we should. > > The issue isn't about sightseeing, although that's always nice, it's > about forcing people to choose between the same overpriced food you ate > for the past two days and possibly missing a session (so you can go out > and get a reasonable meal at a reasonable price). > > [snip] > > Calling any venue that I have ever been in for any kind of a > > conference "a ghetto" is quite an insult to folks that do live in > > "ghettos" or other unfortunate places that I have seen. I don't know > > if it is true now, but as of a few years ago, the IETF had never > > ventured to a country or economy where the expected life span of a > > person was below the global mean/average. Other conferences do > > regularly, "even ICANN." That's where you can see a ghetto - on the > > way from the airport to the 5-star hotel. > > Please. A ghetto is a homogeneous region for some sort of homogeneity. > That could be ethnic but "ghetto" is not necessarily some slur against > poor people or people of some ethnic background. In this case the ghetto > is going to be golfers, most likely affluent ones, in their plus-fours > and some plaid nightmare of an outfit. > > We've already lost the word "niggardly" and the phrase "chocolate > soldier", neither of which have ethnic or racial connotation, to > political correctness. Let's not toss out "ghetto" too. > > Dan. > > > > ___ > Ietf mailing list > Ietf@ietf.org > http://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Ole Jacobsen wrote: > Dave, > > Not wishing to speak for Ray, let me give some general observations: > > 1. IETF meetings require BOTH a suitable venue (meeting rooms) AND a >host organization. Sorry, but it has been demonstrated that a host is not required. It has further been demonstrated that the host (or, rather, the sponsor) does not have to be co-resident with venue. > 2. The host organization have a large say in location (city) >selection, for a number of reasons. We are going to Philadelphia >because that is where the HQ of our host is located, for example. This has been the classic model, yes, but recently has been considerably loosened. > 3. While "isolated" venues may be "problematic", there is always a >tradeoff between a suitable venue (again meeting rooms) and its >distance to nearby hotels and other facilities. In the case of >Dublin, it is anticipated that most attendees will stay in the >main hotel. Having only been party to some of the discussions >around this particular venue I can only say that CityWest was >considered to be by far the best alternative --- in Dublin. Hence the question about priorities. Start with declaring Dublin the venue and it well might be true that this is the best venue. Start with a requirement that the venue have ample resources within walking distance and Dublin well might be disqualitied. It's all about priorities. And no, I would not have queried if I hadn't felt that attendee convenience were not the priority that should be highest, but that it appears not to have been for the Dublin event. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Hi Edward, On Wed, February 6, 2008 10:29 am, Edward Lewis wrote: > At 8:37 -0800 2/6/08, $someone wrote: > >>The descriptions of the venue make clear that, once again, the IETF is >> meeting >>in a ghetto. Periodic bus service doesn't counteract that. > > I really have a hard time being sympathetic to this complaint. If > the purpose of the IETF is open discussion and cross-pollination, > what does it matter where we are so long as there's comfortable > access to the expertise needed? Is there an unwritten requirement > that IETFs are placed to afford us sightseeing? To afford us access > to restaurants? Think about why a beer in a bar in a city center costs 1/4 the price of a beer in the airport of that same city-- captive audience, it's not like you can go anywhere else. Now, this IETF is at a premier golf resort, 15km outside of city center. That means we'll be a captive audience and we will all eat at the hotel restaurant day in and day out and most likely pay far more than we should. The issue isn't about sightseeing, although that's always nice, it's about forcing people to choose between the same overpriced food you ate for the past two days and possibly missing a session (so you can go out and get a reasonable meal at a reasonable price). [snip] > Calling any venue that I have ever been in for any kind of a > conference "a ghetto" is quite an insult to folks that do live in > "ghettos" or other unfortunate places that I have seen. I don't know > if it is true now, but as of a few years ago, the IETF had never > ventured to a country or economy where the expected life span of a > person was below the global mean/average. Other conferences do > regularly, "even ICANN." That's where you can see a ghetto - on the > way from the airport to the 5-star hotel. Please. A ghetto is a homogeneous region for some sort of homogeneity. That could be ethnic but "ghetto" is not necessarily some slur against poor people or people of some ethnic background. In this case the ghetto is going to be golfers, most likely affluent ones, in their plus-fours and some plaid nightmare of an outfit. We've already lost the word "niggardly" and the phrase "chocolate soldier", neither of which have ethnic or racial connotation, to political correctness. Let's not toss out "ghetto" too. Dan. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
On Wed, Feb 06, 2008 at 01:29:40PM -0500, Edward Lewis wrote: > > I really have a hard time being sympathetic to this complaint. If > the purpose of the IETF is open discussion and cross-pollination, > what does it matter where we are so long as there's comfortable > access to the expertise needed? Is there an unwritten requirement > that IETFs are placed to afford us sightseeing? To afford us access > to restaurants? Well, many IETF'ers get tired of eating at the same hotel restaurant, day after day, for the whole week. Also a common problem is that many hotel restaurants are not well equipped to deal with a very large number of people all showing up at the resturant at the same time (+/- 10 minutes), thus flooding the kitchen with orders and resulting in glacial service times. I remember one of the first times we were at Minneapolis, and I made a mistake of eating at the hotel restaurant for lunch, and the food not showing up at the table until something like 5 or 10 minutes before the next working group meeting was supposed to start. Needless to say, that was the last time I frequented that hotel restaurant the whole week! Fortunately in Minneapolis there were other restaurant options that were a close walk away from the hotel. > I am a regular attendee at many other conference series. Although > some series face greater logistical challenges (like venues > cancelling late in the planning, under powered metro and hotel > infrastructures, etc.) and pose less convenient travel arrangements > for the average attendee (using places off the "main grid"), I hear > much less whining from the attendees there than I hear about IETF > arrangements. The IETF is somewhat unique in that it is a fairly large event that still has fixed meeting slots so that everyone shows up for lunch at roughly the same time. That's not so much the case at a trade show, for example, and many conferences are smaller. But basic issues such as access to restaurants and the ability to serve N hundred people in a short period of time are important for anyone who does meeting planning. There are other solutions, such as buffet service, but it is an issue. > Yet another questioned the distance from outside > restaurants[1] - apparently "many fine lunches and dinners" is > required, exercise is immoral. Heh. I consider myself a fairly serious foodie[1], but most of the time when I go to conferences and meetings, especially at lunch time, it's usually a food court style restaurant that I'll frequent, because it's (a) fast, and (b) convenient. Besides, there really isn't time for a proper 12 course tasting menu if you want to get back in time for the evening meetings or BOF's. :-) But what's really, really, annoying for me is if the only restaurant around is a super expensive restaurant at an hotel, where service is slow and you end up being late to the after-lunch or evening working group meetings as a result. Being at a resort hotel often adds insult to injury, because (a) the food is priced comparable to food served at Aquavit or the French Laundry, but (b) the quality of the food is cr*p and certainly not worth the $$$ that you spend *because* it is at a resort location. For me, I'll take business-class hotel like a Hilton or a Doubletree any day and even better if it is adjacent to a mall with a food court. When I go to an conference or a standards meeting, it's to get work done, not to do fine dining or lounge at a resort setting. And if I'm going to pay $$$ for an expensive restaurant, I want to get my money's worth, which is rarely the case at most hotel restaurants. - Ted [1] http://thunk.org/tytso/blog/2007/10/08/sous-vide-revisited/ ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
On Feb 6, 2008 1:29 PM, Edward Lewis <[EMAIL PROTECTED]> wrote: > At 8:37 -0800 2/6/08, $someone wrote: > > >The descriptions of the venue make clear that, once again, the IETF is > >meeting > >in a ghetto. Periodic bus service doesn't counteract that. > > I really have a hard time being sympathetic to this complaint. If > the purpose of the IETF is open discussion and cross-pollination, > what does it matter where we are so long as there's comfortable > access to the expertise needed? Is there an unwritten requirement > that IETFs are placed to afford us sightseeing? To afford us access > to restaurants? I'd like to chime in and remind everyone of one of the basic principles of the IETF in this regard, as well. Just yesterday I was evangelizing the group to an individual from whom I think the organization can benefit greatly, but who had little knowledge of the group as a whole. Thus, I pointed him to the "Tao of the IETF"[1]. As directly-relevant to this issue, I think it's important to remember that we *should not* limit conventions to "nice" areas. Safe, of course, but we don't need to always spoil ourselves with full amenities, golfing, water parks, casinos, and the like. The points I refer to within the "Tao" are twofold. My apologies for sounding preachy, as I know it will look to some like I'm quoting scripture. First, from Section 3: "In many ways, the IETF runs on the beliefs of its participants. One of the 'founding beliefs' is embodied in an early quote about the IETF from David Clark: 'We reject kings, presidents and voting. We believe in rough consensus and running code'. "The IETF is really about its participants. Because of the unrestrictive membership policies, IETF particpants come from all over the world and from many different parts of the Internet industry." To me, that says that we need the input of EVERYONE, not just the select few who can afford to attend conferences in ritzy areas. It also means that the conferences should (as they do) be held at various locations around the world - including "ghetto"-like places. Secondly, from 4.11: "There are many people who have been very active in the IETF who have never attended an IETF meeting." The issue may not be money for a majority of the participants, but why preclude those for whom it actually is? If we choose to hold meetings only in places that offer entertainment and vacation-like distractions, not only will the price likely be higher and more out-of-reach for lower-income participants, but then it seems to me as though we're getting out of the scope and goal of the gathering itself: to teach, learn, and share ideas not to go on vacation with geek buddies. ;-P Bottom line: I think if we limit venues to places where generally only the privileged congregate to spend money on food and wine, while the largest complaint is having to walk a block to the hall, we're outwardly stating that we don't value the talents of those who were born into poverty - or who are even considered lower-middle-class. If what goes on outside of the convention we're there to attend is more important than what's inside those walls, I'd rather stay home. "And that's all I have to say about that." - Forest Gump -- Daniel P. Brown Senior Unix Geek ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
At 8:37 -0800 2/6/08, $someone wrote: >The descriptions of the venue make clear that, once again, the IETF is meeting >in a ghetto. Periodic bus service doesn't counteract that. I really have a hard time being sympathetic to this complaint. If the purpose of the IETF is open discussion and cross-pollination, what does it matter where we are so long as there's comfortable access to the expertise needed? Is there an unwritten requirement that IETFs are placed to afford us sightseeing? To afford us access to restaurants? One of the early negative comments on the site made light of the fact that it was a golf resort[0]. Physical activity is to be discouraged? Yet another questioned the distance from outside restaurants[1] - apparently "many fine lunches and dinners" is required, exercise is immoral. BTW - I have no knowledge of the venue, I've never been to Ireland. I'm reacting to seeing these complaints pile up over the years about nearly everywhere we have been. I am a regular attendee at many other conference series. Although some series face greater logistical challenges (like venues cancelling late in the planning, under powered metro and hotel infrastructures, etc.) and pose less convenient travel arrangements for the average attendee (using places off the "main grid"), I hear much less whining from the attendees there than I hear about IETF arrangements. Calling any venue that I have ever been in for any kind of a conference "a ghetto" is quite an insult to folks that do live in "ghettos" or other unfortunate places that I have seen. I don't know if it is true now, but as of a few years ago, the IETF had never ventured to a country or economy where the expected life span of a person was below the global mean/average. Other conferences do regularly, "even ICANN." That's where you can see a ghetto - on the way from the airport to the 5-star hotel. (Pointers to mail just to say I'm not making this up.) [0] - can't find this in the archive, so here's the copy in my IETF folder: At 21:37 -0600 1/31/08, $someone wrote: ... >We should know by now that isolated resorts ARE NOT ACCEPTABLE as >meeting locations. Even if they're vaguely close to cool places like >Dublin. > >It's not too late. Please cancel the meeting now. Even if it costs a >bunch of money and means we have to skip that meeting date. > >Yes, I'm serious. > >And no, I don't play golf, which appears to be the entire focus of >this sort of location. ... >___ >Ietf mailing list >Ietf@ietf.org >http://www.ietf.org/mailman/listinfo/ietf [1] this is in the archives: http://www.ietf.org/mail-archive/web/ietf/current/msg50069.html. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis+1-571-434-5468 NeuStar Mail archives, backups. Sometimes I think the true beneficiaries of standards work are the suppliers of disk drives. ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Dave Crocker wrote: > Ray Pelletier wrote: >> The venue will be the beautiful Citywest Hotel, "Ireland’s premier >> Conference, Leisure & Golf Resort and one of Europe’s most popular >> International Conference destinations. The four star Citywest Hotel is >> only 20km from Dublin airport and 15km from Dublin City Centre." > > > Ray, > > Every time the IETF has been held in an isolated venue, the experience has > been > problematic. > > The descriptions of the venue make clear that, once again, the IETF is > meeting > in a ghetto. Periodic bus service doesn't counteract that. > > Can you discuss the priorities that led to choosing an isolated venue again? > This choice of venue does not alter my decision process for attending IETF 72 at all. Of course downtown locations are better, but could this be worse than Danvers? ;-) However, there are obvious logistical concerns, especially at lunch time. Is 90 minutes really enough time to bus into town, eat lunch, and get back? Without lots of frequent shuttles, people will be forced to rent a car. I would rather pay a little extra in the meeting fee for shuttles than rent a car for the week. > d/ > > Andy ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Dave, Not wishing to speak for Ray, let me give some general observations: 1. IETF meetings require BOTH a suitable venue (meeting rooms) AND a host organization. 2. The host organization have a large say in location (city) selection, for a number of reasons. We are going to Philadelphia because that is where the HQ of our host is located, for example. 3. While "isolated" venues may be "problematic", there is always a tradeoff between a suitable venue (again meeting rooms) and its distance to nearby hotels and other facilities. In the case of Dublin, it is anticipated that most attendees will stay in the main hotel. Having only been party to some of the discussions around this particular venue I can only say that CityWest was considered to be by far the best alternative --- in Dublin. Meeting venue selection is a bit like engineering itself: You need to make tradeoffs between different requirements. Gold is an excellent conductor, but you won't find a lot of gold power distribution systems for reasons I hope are obvious. Alumi(ni)num seems to be the material of choice at least for the high-power stuff. 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: [EMAIL PROTECTED] URL: http://www.cisco.com/ipj On Wed, 6 Feb 2008, Dave Crocker wrote: > Ray Pelletier wrote: > > The venue will be the beautiful Citywest Hotel, "Ireland’s premier > > Conference, Leisure & Golf Resort and one of Europe’s most popular > > International Conference destinations. The four star Citywest Hotel is > > only 20km from Dublin airport and 15km from Dublin City Centre." > > > Ray, > > Every time the IETF has been held in an isolated venue, the experience has > been > problematic. > > The descriptions of the venue make clear that, once again, the IETF is > meeting > in a ghetto. Periodic bus service doesn't counteract that. > > Can you discuss the priorities that led to choosing an isolated venue again? > > d/ > > > -- > >Dave Crocker >Brandenburg InternetWorking >bbiw.net > > ___ > Ietf mailing list > Ietf@ietf.org > http://www.ietf.org/mailman/listinfo/ietf > ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: IETF 72 --> Dublin!
Ray Pelletier wrote: > The venue will be the beautiful Citywest Hotel, "Ireland’s premier > Conference, Leisure & Golf Resort and one of Europe’s most popular > International Conference destinations. The four star Citywest Hotel is > only 20km from Dublin airport and 15km from Dublin City Centre." Ray, Every time the IETF has been held in an isolated venue, the experience has been problematic. The descriptions of the venue make clear that, once again, the IETF is meeting in a ghetto. Periodic bus service doesn't counteract that. Can you discuss the priorities that led to choosing an isolated venue again? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: FYI - ZDNet and the "Birth of IPv6" referring to the BBC article
Yes, and I realized after sending this that what I had seen earlier (that I mentioned at the end of my note) was just the announcement on January 4th that the root servers would be updated on February 4th. Dan On Feb 5, 2008, at 6:57 PM, Daniel Brown wrote: 2008/2/4 Dan York <[EMAIL PROTECTED]>: FYI, Richard Stiennon at ZDNet noticed that the root servers will be IPv6-accessible and refers to it as the "Birth of IPv6": http://blogs.zdnet.com/threatchaos/?p=527 He was pointing over to the BBC article about this: http://news.bbc.co.uk/1/hi/technology/7221758.stm (I thought the records had gone up into the root servers a few weeks ago so I was surprised to read that it was only today (assuming the articles are accurate, of course).) Dan Coincidentally, there was another ZDNet article I had read earlier today entitled "ICANN turns on next-gen IP addresses". http://news.zdnet.com/2100-1035_22-6229218.html -- Daniel P. Brown Senior Unix Geek -- Dan York, CISSP, Director of Emerging Communication Technology Office of the CTOVoxeo Corporation [EMAIL PROTECTED] Phone: +1-407-455-5859 Skype: danyork http://www.voxeo.com Blogs: http://blogs.voxeo.com http://www.disruptivetelephony.com Bring your web applications to the phone. Find out how at http://evolution.voxeo.com ___ Ietf mailing list Ietf@ietf.org http://www.ietf.org/mailman/listinfo/ietf
Re: [HOKEY] Last Call: draft-ietf-hokey-erx (EAP Extensions for EAP Re-authentication Protocol (ERP)) to Proposed Standard
Thanks for the review Joe. On 2/5/2008 11:26 PM, Joseph Salowey (jsalowey) wrote: > In reading this draft (-09 version) I came up with a few questions and > comments: > > Section 3 - > > Section 3 is a bit confusing it seems that much of the text is section > 3.1 (detailed description of exchanges) should go into section 3.0 > because it seems that much of the process should be the same for local > or remote cases. Currently it is difficult to really tell what pertains > to local, remote and both. > > It does not appear to be clear how the peer knows if it is in the "home" > case or the "local" case, whether the network is capable of ERX (and > vice versa) or how the peer knows what key to use. Perhaps I missed > this elsewhere in the document. We worked to clarify this in the last revision. I will make another pass at it while preparing v10 and run it by you (probably sometime tomorrow). > > Section 4 - > > Section 4.1.1 duplicates text in > internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt. It really > should not. It should reference KDF functions instead of PRFs. I > believe if you replace prf+ with KDF it would be fine. Do you want to > use the naming defined in > internet-drafts/draft-ietf-hokey-emsk-hierarchy-03.txt or are you > specifying your own? Are these key names really necessary? They do no > appear to be used anywhere? This is true. I think we were trying overly hard to name everything (one of 4962 things?) and I realized earlier that we have a procedure to even name the rMSKs. But, it is not clear whether the rMSK names will be used anywhere. I just sent that email about naming and so we should be able to clean this stuff up now if that is acceptable to everyone. On duplication, it seems we have two strong opinions here. You are suggesting less duplication and Alan is suggesting more :). I guess we may have actually achieved the (un)happy medium! My opinion is that we should have less duplication, perhaps to the extent you are suggesting, so the idea is to not have to update (when we need) text in two different drafts. That said, there are some usage specific properties to consider, specifically we are trying to specify crypto-agility in case of ERP and for those reasons, the derivations may need to be spelled out again. In the next revision, I'll see what I can do to reduce the duplication (but before that I will talk to Alan to see what he wants). > > Why such a long key label? Which one? "EAP Re-authentication Root [EMAIL PROTECTED]"? I guess we could call it "EAP rRK" but that might be an abbreviation for something else in the future. Please suggest another name :), but hopefully one that does not involve changing the entire document (I don't want to introduce errors with too many global changes). > > Section 5 - > > Section 5.1 > > What state are you referencing here? I don't think the CalledStation-ID > is what you want to reference, I believe RADIUS routing is typically > done with the username when EAP is used. Why is it only RECOMMENDED to > maintain this state? It seems either it is a MUST or it doesn't matter. > In general authenticators do not do routing, AAA does routing. > Authenticators copy the correct attributes from EAP into the correct > attributes in the AAA message. This seems much more complicated > (routing, multiple attributes TLVs etc). Its not clear if the 3 > sub-bullets of the first bullet refer to what the authenticator needs to > do or the peer needs to do. It seems that the authenticator should be > able to extract a single field from the peer message to determine what > to do with it. Either it will handle it locally or it will pass the > message within the AAA protocol copying the appropriate field into the > message. I see. I will make it clear and separate as to what the peer must and what the authenticator must do. I think we have done that in the sections after that, but I can see the ambiguity. On the AAA stuff and the reference to state, could you please suggest text? Thanks. We should say the AAA client in the ER authenticator to be more precise. I was going to talk to Alan about the AAA stuff later this week, but in the meanwhile, please suggest text in this case and that'll help clean up that text. Thanks. > > Is the integrity checksum a keyed hash or MAC (if so why use another > term?)? Integrity checksum is the most generic term (I would think that keyed hash would not be sufficiently generic; I guess MAC might work, but people have had problems with that word, especially folks with L2 background). I do see that there are references to authentication tags and integrity checksums. There is no need for multiple terms (or at least we should say they mean the same thing). > If so what key is used? If a key is used in the context in the > packet enough to determine the key? Is it possible that more that one > EMSK has been generated by the same peer?
