Re: About cookies and refreshments cost and abuse
pinch of salt I think it interesting that the great minds of the IETF are discussing in depth something that is probably just slightly more important than the outcome of this week's American Idol contest. Oh well, here are my two cents... Cookies seem to be a scarce resource, so why not bring your own darn cookies to the meeting, and you wouldn't have a problem. Seriously, stop by a local grocery store, and plop down $3 and buy whatever kind of cookies make you the most happy. Aggravation avoided. Plop down another $3 and you now have a resource you can use to coerce other people down your path of draft-ness. Need to get a draft approved by your AD? Give him/her a cookie. So if we want to go with the whole ticket route, I say as the IETF, that we go for the whole solution (watch as I open another can of worms)... Badges with barcodes. We get a badge with a barcode. Want a cookie, stand in line, scan the badge. Solves the problem of multiple cookies, just grab everyone's badge. Does it need a human? Nope, just a loud buzzer. Oh, and to give a nod to the TAO of the IETF (I think that's the document) you won't have people standing in front of the cookie table. Move those badge readers to the doors. You then make sure everyone has paid their IETF admittance fee for the meeting. Yep, there are people who use the same badge and just show up. You also eliminate the blue sheets too. No more signing your name, just swipe a badge. You can then use these statistics to see if many people tried to attend the same WG meeting to plan agendas for next year. Do I think cookies are an important problem? Nope. Do I think we should get scanned badges for cookies, and meeting room admittance? Probably not, but I think it would be cool. Do I care when I have dinner? Nope, I either bring my own snack, or I just tough it out like the Internet Nerd Pioneer I one day hope to become. Cheers --Brett /pinch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Wireless at IETF
2 parts to this message, read it all for twice the fun :-) Given the amount of damage due to time wasted for other participants, it might be worthwhile to print it up ahead of time and include it in the registration packet. The cost of a ream of paper is small relative to the lost productivity this causes. Heck, maybe even put it on the IETF web site ahead of time. --Paul Hoffman, Director --VPN Consortium 1Wireless at IETF We tried this once. It is hard to determine how well it worked because if they fixed it, we didn't know about it (as they blended in to the background infrastructure). Seems to me that most of the people running in ad-hoc mode don't even know it (thus, why bother to read the sheet). Continuing along those lines, sometimes Working Groups have been known to put MAC Addresses on the screens of people in the room (running ad-hoc). I don't know how much success this has either, as the networks still stay up and running. I'll see if I can dig out the How to turn off ad-hoc mode sheet from a few meetings back and send it to the upcoming hosts. We have tried to solve some of these problems by taking the MAC addresses of those doing mean things to the net, and stuffing them in a Penalty Box so they would come down to the terminal room, and we could track them to a switch port. I actually think this worked pretty darn well. Much of the problem was (wo)man power. We didn't have enough people to run the network, and enough left over for a brute squad. Hopefully with more companies coming back to host the networks (YAY, Thank you!!) we can start doing cool things like this again. 2Ad-Hoc mode in airports/airplanes So at the talk that started all of this at shmoocon (I haven't reviewed the slides, I'm just going from what I remember from the talk). A few extra notes. The issue was ad-hoc mode on the W-NIC and the goofy 169 address you get from 3927. Microsoft said they would patch this in their next service pack. Patch the fact that you get the auto address or work to disable ad-hoc. Chances are that it would be the auto address. (So then you setup a DHCP server, also mentioned in the talk, and you are back to square 1) MS was there and a rep. said that it was made so you and a bunch of your co-workers could walk outside of the building at lunch with your laptops, and the network still appears to work. I'm guessing he is going off of the fact you would only share networking interests with your buddies, unless they are coming up with some kind of link local grid that has one card acting as a bridge back to to the main network implementation. (Pure speculation) Simple Nomad also discussed during the presentation that he was tinkering with his (recalling from my full brain from the weekend) Palm OS, and this it may also have a problem too. (Add another doc to the IETF packet) Anyway to sum all of this up, some of the people he was playing with were on the plane and unpatched. While I hope expect (more hope I guess) that the people at an IETF meeting are more saavy than the plane riders, can you imagine walking up to one of these people and handing them a note on how to turn of ad-hoc networking on their wireless lan card? I'd imagine you would get a response similar to handing them a document on how to engage the CAT 3 ILS and land the plane. Simple if you know what you are doing, totally alien if you don't. Cheers! --Brett ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Engineering our way out of a brown paper bag [Re: Consensus b ased on reading tea leaves]
I wonder if that time frame represents the amount of critical mass turnover for these topics to be refreshed, but previous discussion forgotten. I don't know if there is something that would fulfill this roll, but from 40 feet back, here is a suggestion. A bulletin board (Not BBS, but like an old cork one). Take what Brian said, that we need to look at this in sections. True. Take what Eric said, we are doing that, but different people at different times at different sections. True. Wouldn't it be nice to compartmentalize some of these systematic functions, but still keep them as neighbors so that if someone wants to talk about _requirements_, you step over and look at that section, and all the notes that people have stuck to the board. If someone wants to look at _solutions_ they look there. If they just want an overview, they glance at the whole thing. If people think an idea is not great, it gets stuck to the bottom, if it is well liked by many, then it bubbles up to the top (allowing many to bubble up or down). The reasons could be discussed on the list, but the result might end up on the board. What is nice is that if we just shrug our shoulders and walk away from it, we can come back to it in .5-3 years time and look back at this simple cork board rather than spilling through mounds of mail archives. I think (after watching the IETF for a while) that a fair amount of time is spent rehashing good ideas (and bad ones). Maybe a cork board that a newcomer could come up to, see the note, see the notes about the note would be useful. (Think persistance of knowledge in the new-comers orientation information presented at each IETF). Again, I'm just tossing this out there as a brainstorm idea. I think the problem (ID-Format) is real. I think it is solvable. I think we have too many great brains jumping around the systematic process of solving it, thus spending time on thought swapping and bringing newcomers up to speed. In other words, an e-mail list might not be the best way to solve the problem, and an e-mail archive might not be the best way to keep the summary knowledge around and accessible for newcomers to the task. --Brett I agree. As usual we seem to be stuck in an infinite loop on this mailing list with the cycle being somewhere between 6 months and 3 years. Eliot Gray, Eric wrote: Brian, I think it is somewhat unfair to say that we have not tried the steps you outline below. Where we run into trouble is when different sets of people disagree as to which of the steps we are currently working on. Quite frankly, I believe we can address the second step (which of the requirements are not met today?) with a firm none. This is - IMO - the basis for the apparent stodgy resistance to change. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- On Behalf Of Brian E Carpenter -- Sent: Thursday, January 05, 2006 7:36 AM -- To: Harald Tveit Alvestrand -- Cc: ietf@ietf.org -- Subject: Engineering our way out of a brown paper bag [Re: -- Consensus based on reading tea leaves] -- -- Harald Tveit Alvestrand wrote: -- -- -- --On mandag, januar 02, 2006 18:10:15 +0200 Yaakov Stein -- [EMAIL PROTECTED] wrote: -- -- The only thing I am sure about is -- that -- consensus on this list is for keeping everything exactly -- as it is. -- -- -- I'm pretty sure there's no such consensus. -- -- I do, however, see a rather strong -- consensus-of-the-speakers against -- using MS-Word document format for anything official. -- -- I think we need to tackle this whole issue, if we do decide to -- tackle it, in a much more systematic way. -- -- - what are our functional requirements? -- - which of them are not met today? -- - what are the possible solutions, and what is their practical --and operational cost? -- - which, if any, solutions should we adopt, on what timescale? -- -- I believe that if we took a systematic approach like that, the issue -- of how we determine consensus would be broken into enough small -- steps that it really wouldn't be an issue. -- -- Brian -- -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Please note that my e-mail address has changed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IEEE vs IETF (one more time) was RE: Please make sure that you do not run your WLAN in ad hoc mode
Hardly a fair comparison. It is so evident I'll just sum it up. IETF meetings support the entire organization for the entire year (or at least a third of it). Yeah yeah, blah blah ISOC insurance... IEEE makes money in all sorts of other ways, including IEEE Dues to say the least. I haven't tried very hard, but in 30 seconds of surfing, I can become a year long member in IEEE $156, attend one meeting $300, and get one specification [picked one at random] $109. I think it would be great to get a firm price on how much it would cost to outsource the network. We would finally get people to realize the value they are getting by having hosts and volunteers. --Brett I can ask, but I doubt that this information is available. What I know is that the registration fee for the IEEE 802 Plenary meeting is considerably lower than the one at the IETF (300 USD vs. 500 USD). Regards, Dan -Original Message- From: Marshall Eubanks [mailto:[EMAIL PROTECTED] Sent: Saturday, November 12, 2005 7:11 AM To: Romascanu, Dan (Dan); Avri Doria; Ole Jacobsen Cc: ietf@ietf.org Subject: Re: Please make sure that you do not run your WLAN in ad hoc mode On Sat, 12 Nov 2005 06:45:59 +0200 Romascanu, Dan \(Dan\) [EMAIL PROTECTED] wrote: Dear Dan; You should see if you can find out what it costs the IEEE 802 to outsource the wireless LAN, both total and per person. Regards; Marshall Eubanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Avri Doria Sent: Saturday, November 12, 2005 4:15 AM To: Ole Jacobsen Cc: ietf@ietf.org Subject: Re: Please make sure that you do not run your WLAN in ad hoc mode On 11 nov 2005, at 13.56, Ole Jacobsen wrote: In 19 days, this very hotel and meeting rooms will be filled with ICANN attendees, most of whom are not technical in our sense of the word. That should be lots of fun :-) It will be interesting to see if ICANN has as much trouble, or IEEE during the intermediate week. I have heard an interesting bit of anecdotal evidence that indicates the situation is worse at IETF meetings then at other meetings. I questioned it, but who knows? a. I know. I am attending both the IEEE 802 Plenary meetings and the IETF meetings for many years. I can witness first hand that the situation is much worse at the IETF meetings than at the IEEE ones. Practically, the network is perfect at most IEEE meetings. True, I believe that they are outsourcing the network deployment and its maintenance during the meeting. As I will be attending the IEEE 802 meeting next week (in Vancouver, but at a different hotel) I will be able to report by the end of the week how it was. Anyway, it hardly can be worse than at the IETF meeting. During this whole IETF week I could almost never connect during the meetings. I had to wait for the lunch break when everybody was away, or to go to my room (at the 7th floor in the tower) to be able to connect to the IETF wireless network. Regards, Dan ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Please make sure that you do not run your WLAN in ad hoc mode
It is hard to be very strict at an IETF meeting. We first started running Penalty Boxes at one of the Minneapolis IETF meetings. Why did we do it? Because we had time. We got the network working reasonably well and could dedicate our time to ... Fighting Evil. So we setup the penalty box, and we put people in there. We found a mean MAC addr, set it all up, and then came the question.. Do you really want to do this? That was a hard call to make honestly. There were a lot of smart people in the NOC (There always are). Even with all that intelligence, you could feel the tension in the room as we put 'em in there. Why? Well we have enough people bashing the NOC crew all the time. Now we were purposefully messing with people. How would you like to be the person that accidentally put the IETF-Chair in the penalty box? So we put quite a few people in there, and we caught at least one (Thanks Joel). Was the guy actually doing malicious things. We think so. Did he act like he didn't know what was going on? Yep. Did he unplug his computer as soon as we found him, yep. It was all very odd. Somewhat rewarding, but still weird. Ok, let's sum this up. 1. The people who are running in ad-hoc mode, if you look at a few of those nets, you will see multiple MAC addresses for the same network. Look closer and some of the OUI's look downright spooky. You could be chasing them for quite some time. 2. As someone else pointed out, they would only feel the effects of your efforts if they connect back to the IETF network. Do you think they will? 3. One of the ways we caught the person in Minneapolis was because of the goo coming out of their WLAN card (scanning), we shut them off, and then saw the same goo coming out of their wired port. Doesn't apply to well to wireless ad-hoc. I bet you can catch some of the people, but in the end it is probably a pretty low priority compared with tuning all your APs so the wireless coverage at the plenary doesn't crash into itself. I think training would be great. The only problem is that either they are doing it to be mean, or they have no idea they are doing it in the first place and skim over the documentation asking them to check their config as if it were a note well. I'm all for the Penalty Box, I thought it was cool. But looking at that list of Ad-HOC nets and MAC addresses. Wow, that's a lot! Best of luck to the NOC team, and thanks to UofO for the MP3 streams. --Brett I think we should be very strict on this. All this people should get filtered until they go to the NOC and make sure to get trained about how to avoid ad-hoc ! Regards, Jordi De: Glenn Parsons [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Thu, 10 Nov 2005 14:42:07 -0500 Para: IETF Discussion ietf@ietf.org Conversación: Please make sure that you do not run your WLAN in ad hoc mode Asunto: RE: Please make sure that you do not run your WLAN in ad hoc mode FYI, At the plenary last night the NOC team noticed 107 adhoc networks on 802.11b. See attachment for the names MACs. Cheers, Glenn. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pekka Nikander Sent: Thursday, November 10, 2005 2:06 PM To: IETF Discussion Subject: Please make sure that you do not run your WLAN in ad hoc mode It would be nice if people did not run their WLAN cards in Ad Hoc mode. Here are MAC addresses of some cards that I currently see advertising various ad hoc networks. At least some of these were present also in yesterday's plenary. Network name MAC Netgear02-00-10-62-A3-6D IETF64 02-00-31-9B-69-47 Netgear02-00-61-76-D2-79 linksys02-0C-F1-EC-CF-9E TC_2 02-0E-35-03-D4-C4 IETF64 02-12-F0-00-33-FD wireless 02-27-97-94-65-56 If you don't know how to check your MAC address or how not to turn off ad-hoc capability, it may be better to turn off WLAN altogether. Thank you, --Pekka Nikander ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Information available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. -- Please note that my e-mail address has changed. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Meeting Locations
I have to say that every time we went back to Minneapolis, they got friendlier. It also made our job easier because they knew what we needed, and it wasn't a shock to them. Having extra tables in the common areas, allowing us to wire up the bar, asking them to turn off their wireless, and advanced access to rooms in the middle of the night were all things they didn't have to be talked into. The _knew_ having IETF access points in the bar meant extra sales. The IETF meetings are quirky. No doubt about it. They move a lot too, so running into the ownership thing with IETF isn't too dangerous. Most of the hotels we went to usually were trying to get us to come back. The largest problem with a 2 year proposal is getting the host. It was easy back in the day when a location could be chosen, and then a host was happy just to host it. Now the host has some pretty significant costs in relation to bottom line profits. So it makes sense that the host needs to be involved with that selection. Making sure that the host is around, solvent, and willing to make the bits fly at show time is a consideration. (That and if they agree to it 2 years in advance, they then have 6 meetings to attend and realize it may not be something they really want to do and back out!) Minneapolis was great though. They knew us, we knew them, we all liked each other, and it was a good situation. Keep up the good work IETF! --Brett Thorson --On tirsdag, juli 19, 2005 07:09:16 -0700 Dave Crocker [EMAIL PROTECTED] wrote: As noted in the current thread, early site selection permits attendee budgeting. From the IETF side, it permits serious negotiating for site terms and operational efficiencies when a previous site is re-used. Minneapolis has been a useful demonstration of this latter point, I think. Since nobody but Foretec has seen the Minneapolis contracts, we have no idea whether that's true or not. I've had it argued at me that a hotel that believes it owns the event is actually harder to negotiate with than one that believes that there are alternatives. Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
IETF onsite networks; discussion, cash, knowledge
Mr. Crocker Mr. Hain, I use this message only because it was available, and it somewhat sums up the assumptions and conclusions reached previously many times. I use it as an outline only. Please do not view this as any kind of comment on you or your thoughts, words or expressions directly. To the IETF @ Large; On Thu, 17 Mar 2005 07:51:27 -0800, Tony Hain wrote: The fact that Actually are considered 'emergency' at this point shows that in fact people do expect new features from the equipment, it shows that SOME people decided to add new features. Actaully not. It shows that new features came about because of the available hardware. Why deploy 15 Cisco 340's that all need firmware upgrades when you get an offer by Company X to give you new, easier to manage hardware, that has added value that will make it easier to find problems before IETF-ers-at-large start grumbling under their breath about it? Maybe you have an answer. But have you been on even one of the NOC teams for IETF 58 through 62? If no - Mod down 20 points, then re-evaluate. it does not show that the network really needed them. Scenario: Ad-Hoc networks. discussion Before: There is an ad-hoc network somewhere on the x floor. They are sucking people into them. People are complaining. Person from company X walks by: Hey I have a product that will pin point that person so you can show them the light After: Hmm, not as many ad-hoc networks. We can exclude those people from the net so we isolate them. Extra features that come along for the ride, maybe not as proven as previous, but those new features do help the ALL VOLUNTEER NOC TEAM to isolate some of those problems. and the difference between these two points is exactly where open discussion and agreement among the ietf meeting participants could be helpful. Open discussion would be great. However, on this list, probably not the best. I think IETF people are great, and very smart people. But from watching the re-org procedure, there are many want-to-be lawyers, accountants, business executives, etc. I'm sure there were many people commenting on those topics that actually were official members of those professions. The point I am making is that running an IETF NOC is so different that at some point in the interest of the signal to noise ratio we have to let the bodies in the trenches fight the war and come to that table with their comments and quite possibly tone down the comments of IETF meeting participants. While their comments should be welcome, they simply don't have the view from both sides of the switches APs. I'm all for dicussion, but if your name hasn't been on at least one thank you list for NOC team IETF now minus five inclusive then chances are your opinions are welcome but possibly not up to date. Scenario: Wired drops for the presenter, jabber scribe, etc. This would be great. However, this of course adds hardware. Quite a bit of it. I put a switch in a central like location and secure it, POE the AP's and run 4-6 AP's in multiple rooms with 4-6 CAT5 cables. Now, I need to put breakout switches in each room, secure them, tape down the cables, possibly pull the cables and put them back down if the meeting rooms get used by other groups. I need to ship the cables, and the extra switches, along with the security cables. These issues continue. Result: This is no reason that this cannot be accomplished. Why is it difficult? Security, time to deploy tape down cat5 cable, shipping and acquiring extra hardware. Consequence: It is easy to say, this should be done. It's great to talk about it and come up with the 7 ways it can be accomplished. It would be perfect if you could pay for it too. Until then, you are back to getting what you pay for. right now, the folks doing the choosing pretty much have to guess what the folks doing the using want/need. open discussion could eliminate the guessing. Choosing would be an excellent gift to have when doing a non-hosted terminal room. When there isn't a host, you take whatever you can get. When I did my first terminal room in San Francisco, Cisco stepped up to the plate with 2 pallets of gear. I still had to worry about: Terminals, wiring, placement, extra routers, extra switches, fiber, this list continues ad nauseum. Choice you say? My choice was either Cisco (which worked fabulously I might add) or to be incredibly delusional and wait for something else. if, as some have voiced, the community of attendees feel it is essential that we eat our own dogfood of new features, on our meeting production network, then we will have agreed to the consequence, assured lack of stability. if instead the community feels that reliability for a core set of functions is paramount, then new features can only be added after they are viewed as stable and low-risk. Which all goes out the window when you settle for the You get what you don't pay for scenario. Unless you a throwing money
Re: IPv6 in the network, please
Sorry to send this back to this list. But if people are having problems, I would encourage them (as well as yourself) to come to the NOC (at any IETF, this one or any future IETF). That way we can ask questions like What is your MAC address and offer a solution as quick as possible. In any case, the solution, as far as we can tell, is that your ability to receive DHCP offers on your linux system is broken. Here are the logs. If you have more issues, I highly encourage you to either take the problem to a Trouble with DHCP on linux list or come to the NOC to continue the exploration. Cheers! Nov 8 15:27:52 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:27:53 (none) dhcpd: DHCPOFFER on 130.129.134.174 to 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:29:35 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:29:36 (none) dhcpd: DHCPOFFER on 130.129.134.174 to 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:29:43 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:29:43 (none) dhcpd: DHCPOFFER on 130.129.134.174 to 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:29:59 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:29:59 (none) dhcpd: DHCPOFFER on 130.129.134.174 to 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:30:59 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:30:59 (none) dhcpd: DHCPOFFER on 130.129.134.174 to 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:30:59 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:30:59 (none) dhcpd: DHCPOFFER on 130.129.134.174 to 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:32:32 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:32:33 (none) dhcpd: DHCPREQUEST for 130.129.134.174 (130.129.16.20) from 00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80 Nov 8 15:32:33 (none) dhcpd: DHCPACK on 130.129.134.174 to 00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80 Nov 8 15:53:21 (none) dhcpd: DHCPRELEASE of 130.129.134.174 from 00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80 (found) Nov 8 15:53:32 (none) dhcpd: DHCPDISCOVER from 00:05:4e:40:17:62 via 130.129.128.80 Nov 8 15:53:33 (none) dhcpd: DHCPOFFER on 130.129.134.174 to 00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80 Nov 8 15:53:33 (none) dhcpd: DHCPREQUEST for 130.129.134.174 (130.129.16.20) from 00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80 Nov 8 15:53:33 (none) dhcpd: DHCPACK on 130.129.134.174 to 00:05:4e:40:17:62 (silkesvarten) via 130.129.128.80 Nov 8 16:17:19 (none) dhcpd: DHCPRELEASE of 130.129.134.174 from 00:05:4e:40:17:62 (silkesvarten) via 130.12 --Brett On Wed, Nov 10, 2004 at 02:18:31PM -0500, JORDI PALET MARTINEZ wrote: Agree, good job. Is working for me since over 10 minutes ago. Not for me. But interestingly, I've never been able to get an IPv4 address (or any responses) to DHCP queries from dhcpcd-1.3.22_p4 on Linux on the v4 network. However, I managed to get a response and an IPv4 address on the IETF61IPv6 network. Stig ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
802.1X Instructions
802.1X Instructions IETF 61 Washington Hilton To use 802.1X: 1. Associate to SSID: IETF61dot1X 2. Use PEAP/MSCHAPv2, TTLS/PAP, TTLS/CHAP, TLS 3. Do Not Verify Server Cert and we wont verify yours :) 4. UserName and/or Realm can be anything, as well as outer tunnel identity for TTLS. ex. [EMAIL PROTECTED] 5. password must be passwordietf61/password This is not intended to be truly secure. It is here as both an exercise for our own amusement and to offer a way to get those wep keys rolling. If you find this helpful please enjoy and feel free to give us feedback. If not, there is an open wireless SSID== IETF61, and an ssid with WEP --SSID==IETF61WEP for you use. The WEP Key for IETFWEP is ascii-keywepisinsecure/ascii-key hex-key7765706973696e736563757265/hex-key --IETF61 Noc ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Money Exchange
I asked the Lotte hotel where I could use my US bank card to extract cash. They pointed me towards an ATM (Global Cash Service) in the underground nearby. However, as myself and several others have found, this machine has been timing out since Friday Night. I have since found a new Global Cash Service machine on the 11th floor of the Lotte Department Store (Food Court) to the right of the blue fountain. It worked great. Cheers! --Brett
ietf-mx
The MX server was beaten into the world of swap this evening by Spam Assassin. I have made some changes that will hopefully allow it to continue until we can get some more memory for it. You may receive some bounce messages if you tried to post to IETF.ORG lists between 3:30PM and 5:45PM. Please check your bounces, and repost. Sorry for the inconvenience. --Brett
SA / Spam. Facts.
These are the facts. On Wednesday 17 December 2003 16:01, Dean Anderson wrote: This is ridiculous. The IETF is not getting a lot of spam, so adding SpamAssassin headers is a solution in need of a problem. a lot is a subjective term. Also, unless you are sniffing the traffic into our network, would you know how much spam our MX receives? A rough approximation is that 1/3 of the mail into the IETF MX is spam. Estimate based on a small sample. If a more accurate number is needed, please submit to the tracking system for prioritizing in the queue of IETF things to do. Some spam we already filter out without spam assassin. For example... CC'ing mail to ietf-announce (as two of your posts did) gets caught in our spam filter because it is not appropriate on that mailing list. [EMAIL PROTECTED] wrote: ...this implementation is to allow the IETF community to get used to having these headers in the messages, and allow us to make any changes to the filtering rules. The above seems like a thinly veiled attempt to make SpamAssassin headers a defacto standard supported by the IETF, without going through the standards process. It may seem that way to you, but in reality it isn't. Just me deciding to use it because it worked well with exim, it was quick to setup, seemed to perform the task well, didn't need a lot of human intervention, it could be tuned. Oh, and it's free, so the IETF could afford it. Mr. Anderson continued Obviously, if the goal is to standardize these headers, then a standard can be produced and put through the standards process. The goal is to reduce spam, and reduce the human intervention needed to reduce spam. These are the facts. --Brett
Re: report on the wlan difficulties in IETF?
Jari, I will be working on a summary document that pulls together the technical items we witnessed at the meeting. --Brett On Wednesday 19 November 2003 08:15, Jari Arkko wrote: Hello, I wonder if anyone has documented the situation of the IETF wireless network and analyzed the experienced difficulties? I'd be interested in looking at the causes of the difficulties. There's a lot of anecdotal information about the capabilities of the protocols and advice on what to do on this list. But it would be good to know what was the real cause of difficulties. Say, its pretty useless to authenticate beacons if the radios are simply swamped by too many nodes who think they are access points. Similarly, access control a la 802.1X does not help if the interferences are caused during or before access authentication has taken place. Or a correctly operating radio network is no good if all of its capacity is used by the legitimate, but infected, hosts for something non-productive. The bottom line is that finger pointing (staff, ieee, fcc, ourselves...), if useful at all, should come after we find out what happened. I suspect the IETF network is pretty the worst case scenario for current wireless LANs (or can someone point an even more demanding case?). But what we do today will be done tomorrow by regular users... --Jari
Plans for IETF - 60
I am hoping to get this done in time for IETF 59, but with current workload here at the IETF, I am going to aim for 60. 1) Make a form used for meetings where people can submit wireless reports. Require certain data be submitted (Location, computer, NIC, user) 2) Make a form where people can submit end of meeting wireless opinions. One opinion to an attendee. 3) Write up a new terminal room / IETF MeetNet document. When I am ready to accept public input review regarding these documents, I will post a message. Thanks. --Brett
IETF58 - Network Facts
I am still collecting data from the IETF 58 network, when I can state additional facts I will post them along this thread. Until then, here are some facts that correct messages posted previously. All wireless access points were set at 1 milliwatt on channel 6 when they were first deployed. On and after Monday these value were changed. We did not run all access points on 1 milliwatt on channel 6 beyond Sunday night. 10% of the community using a wireless NIC was operating in ad-hoc or AP mode at some point during the meeting. I noticed many people in the terminal room using a hard wire connection. When I did a non-scientific survey of a sample of these users, they did not have a wireless card at all. Cost of the terminal room is not appropriate here. If these volunteers didn't step forward, there would be no network. Double or triple the meeting fees, it wouldn't cover the cost of suitable replacements for the talented volunteers or the hardware on temporary loan. I've run those numbers, those are the facts. ---In other news-- (Think Red Cross, don't think Power Company) I had six people come up to me on Thursday to let me know that their wireless connection was acceptable (they used words like great, and no problems). I hope that more people would take the time to document their positive experiences. This will give us more perspective on the total experience and it is the only payment these volunteers get from this community. At this point, we know the issues, we know the complaints. Right now, it would be nice to hear where the network did work, and some positive comments. A message to [EMAIL PROTECTED] would be great. I am going silent on this list for a while, don't want to stir things up too much. Responses will be made privately if warranted. --Brett
Re: [58crew] RE: IETF58 - Network Status
On Thursday 13 November 2003 14:46, Romascanu, Dan (Dan) wrote: Yes, this looks to affect some models of cards and drivers more than other. Unfortunately, I fell this time in the unlucky category. The same model of card, driver, and OS that worked perfectly for many in many other similar events, including the last three or four IETF meetings made my work impossible this whole week with the wireless setting at this IETF network. On this respect this was - for me - by far the worst IETF since I am using wireless connectivity. Sorry guys. The only thing thing you have to be sorry for is not coming to us sooner. If you had come to us sooner, we could have been able to solve some of your problems or fix it all together. We hope that by working together to solve these problems we can help you out. I have heard many comments from many people that this has been a great wireless IETF. We identified several client problems, and we saw a larger number of infected machines. If the wireless did suffer (which I don't think it did because of our volunteer team who worked VERY hard and configuring it) it was due to problems simply beyond our control. And as always, we are happy to take in more volunteers. If there is something you don't like, hop on board and solve the problems! Cheers, and I hope to hear more from you, in realtime next time these issues pop up. --Brett Dan -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roland Bless Sent: 13 November, 2003 7:08 PM To: Randall Gellens Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: IETF58 - Network Status Hi Randall, I have been consistently unable to maintain a connection for more than a very few minutes, usually not even long enough to establish a VPN tunnel and fetch one message. The 802.11 coverage comes and goes; the APs seem to vanish and I see nothing for a while, eventually the network comes back but only briefly. This has been I can partly confirm your observations, since I often see my driver reporting a signal strength of 0 for seconds. The connection is somehow unstable as my log also reports (NSIS meeting this morning, actually not crowded) Nov 13 10:41:01 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:41:03 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:41:25 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:41:26 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:42:58 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:18 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:18 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:18 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:45:23 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:45:24 kernel: eth1: New link status: AP In Range (0005) Nov 13 10:45:54 kernel: eth1: New link status: AP Changed (0003) Nov 13 10:46:28 kernel: eth1: New link status: AP Out of Range (0004) Nov 13 10:46:28 kernel: eth1: New link status: AP In Range (0005) ... and so on... however, it seems also to depend on the cards firmware and driver, so other people may have no problems at all... Inspite all the problems, it works well enough to get things actually done. the case in every session I've attended, as well as tonight's plenary. It doesn't seem to matter if the room is crowded or empty, or where I sit. I have attempted to only select the 'ietf58' network, but often the network vanishes and there are no networks visible; other times the only visible network is an ad-hoc calling itself 'ietf58'. I wasn't often successful to reattach to APs after my card was hi-jacked to ad-hoc cards announcing ietf58. Setting the essid again to the same value seems to do trick, however, often I see signals of strength 0 (maybe the card is confused then..). Furthermore, it happens often that I don't get an IPv6 address directly after activating the card (maybe the RA doesn't get through). Cheers, Roland ___ 56crew mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/56crew
IETF 58 - Network Status - 11/11/03 - 10:45AM Local Time
We have made some changes to the network and access points. The reports that we are hearing is that the network has improved. We are always interested in your field reports. Some of the field reports that we are getting are regarding rogue access points. One such access point is SnowNet. Please check your machine for this network and kindly disable your AP. We are still getting reports of people getting pulled over to machines running the IETF58 SSID in ad-hoc mode. Please make sure you are not running in AD-HOC mode. To use the IETF wireless network exclusively on Windows XP, please choose the Access Point (infrastructure) networks only option, which is available by clicking on Wireless Properties, then selecting the Wireless Networks tab and then clicking on Advanced. (K. Almeroth) If you do detect machines in AD-HOC mode or machines that are rooted and being bad net citizens, please provide us with with as much information as you can (Including MAC Address), and we may look into take some kind of corrective action. Special thanks to our kind NetOps volunteers K. O'Donoghue and C. Elliott for the tremendous effort they put forward to tune the wireless. If you see them in the hallways and byways, please be sure to thank them. Also, the all Volunteer NetOps crew is wearing Green Dots on their name tag. If you see any of them, please be sure to thank them for coming to the IETF and volunteering their services to provide this meeting with a network. --Brett
IETF58 - Network Status - 12:05PM Local Time
We currently have three external routes, all are up. Wireless has been deployed to the hotel, and we are still working to get good signal coverage to the Brit's Pub. We have a solution that will start to get executed later this afternoon. That should dramatically increase the coverage in that bar. We have a Vivato wireless switch located on the roof. This is washing the downtown area from Brit's Pub to The Local. We have been getting some reports of rooted machines (IETF Attendee machines, not IETF NOC Machines) that are scanning and causing a lot of traffic on the network. IP Addresses are: 130.129.139.106 130.129.139.203 Please check your machines for these addresses. If they are yours, please stop by the terminal room, and ask for help. We are monitoring the mailing list [EMAIL PROTECTED] for problems. Comments, suggestions, issues are very welcome here. We would rather hear of a problem many times on the list, then not at all or by way of rumor through the meetings. Please let us know your concerns. Thanks much! --Brett
IETF58 Network - DHCP Leases - ARP Traffic
We have been seeing a lot of ARP traffic come over the routers, the results of external scans. In an effort to reduce the ARP traffic broadcast to the wireless network, we are decreasing the size of the wireless address space to clear out unused addresses. We would then blackhole requests for those addresses not given out. In order to expedite the reclamation, we are setting the DHCP lease times to a low value to help us clear out addresses in the space we would like to blackhole. Once we have executed this plan, we expect to put the lease times back to previous settings. Thanks to all those who helped come up with this solution and execute, and especially all those on the NetOps 58Crew. --Brett
IETF56 Network Status 2003-03-18 01:10
You may have noticed a slight disturbance in service Monday night. We were doing some reconfiguration of the network to fix some DHCP issues with 802.1Q. We are going to watch the DHCP server Tuesday morning to make sure our changes have the desired effect. During the earlier degradation of service many people came to the NOC to let us know about their issues, and I'd like to thank them for that. I'd like to encourage everyone to contact the list [EMAIL PROTECTED] with any issues regarding the network (Stop by the California room if you have connectivity problems). We have made some wireless modification in the ConBall rooms. This was done after the meeting to reduce disturbing meeting participants. Once the meeting rooms fill with people, we will once again do another site survey. If you are running a Win2K machine called Trevi MAC address 00:02:0a:35:08 please come to the Helpdesk. Thanks much for your patience, and to all those who helped and offered help. --Brett
IETF56 Network Status - 2003-03-18 17:30 PST
Knock On Wood At this point in time, we are not seeing any issues with the network. /Knock on wood We have heard that some computers are seeing the wireless network disappear at times. These reports seem to come from Windows users, but we don't have enough data to classify this problem yet. If you do see an issue with wireless, would it be possible to ask the person next to you what they are seeing, and comparing status and information. Sending this data (along with time, location, and other debugging info) to [EMAIL PROTECTED] would help us to collect more information, and make changes if necessary. We made one last change to the DHCP server so when you come back from Starbucks (or other networks) your computer should obtain a DHCP address faster. The SunRays located along the wall in the Terminal room are open for anybody to use. If it has a SmartCard in it, feel free to start using it. If there is no SmartCard, you can either choose to use it as is, or to ask the helpdesk for one. When you remove the SmartCard from the SunRay, your session will be swapped to disk. Come back, insert card, and your session will be swapped back to any SunRay in the terminal room. These machines will obviously work without SmartCards, but you would then lose the session save feature. Once again, I'd like to thank those attendees who have offered their help, and the NOC staff (look for the green sticker) who have done a fabulous job. Cheers! --Brett Thorson
DHCP Problems
The NOC staff has been hearing rumors, grumbles, hints and innuendos that DHCP is not handing out addresses to a few people. If there are users with issues, please report them to the NOC/Helpdesk staff. Once we know the problems, only then can we find the solutions. [EMAIL PROTECTED] is our mailing list. If the network is totally inaccessible then running by the California room would be greatly appreciated. --Brett Thorson Foretec Seminars / IETF
IETF56 Network Status - 2003-03-16 21:30
Ladies and Gentlemen of the IETF. I wanted to take this time to thank you for your patience and assistance with the IETF56 network. Right now we seem to have a stable network. Our earlier problems with DHCP and DNS have been resolved. We have tried to balance out the Access Points in the public areas. With many thanks to Greg Shepherd, multicast availability has been greatly improved. Please bear in mind that multicast is available in the hotel only over the wired connections in the terminal room. At this point in time the only known issue concerns suboptimal IPv6 routing. We are actively working on this issue and hope to resolve this shortly. If anyone has a local tunnel they would like to let us use, we would be glad to entertain your offer. If you discover any issues please let us know by posting a message to [EMAIL PROTECTED] I would like to take this time to thank (for the first of many times) the NOC staff. These ladies and gentlemen have been working miracles and wonders to bring this network together. --Brett Thorson Foretec Seminars / IETF
