Re: i18n name badges
On 20-nov-03, at 4:05, James Seng wrote: I think having the punycode form have no value on a name badge. Punycode, as it is designed, is meant for machine-to-machine communication. So why don't we come up with a machine-to-human transliteration mechanism? So if someone called (trouble with spamcontrol again...) a translation table could turn this into Zeus and back again where appropriate. If the translation table doesn't know this could be translated into ZITA-epsilon-ypsilon+grave-sigma, which isn't great but still much better than just numbers or base64 or whatever. But I like the idea of allowing participation to put their own native names together with their ASCII version on the name badge especially for the next IETF. But... 1. What if the person don't have ASCII only name? (e.g. Patrik Fltstrm) I guess do the same thing as is being done today... 2. What if the person have a name which the computer cant be printed? (Maybe it is not in ISO 10646, maybe it is but there is no fonts, maybe the fonts is there but the rendering is wrong?) Easy enough: allow people to supply a graphic.
RE: IETF58 - Network Facts
BNSF (Burlington Northern and Santa Fe Railway) has started to deploy Wi-Fi wireless LAN systems extensively in rail yards to allow crews to remotely control engines used to make up trains. These Wi-Fi systems are connected to a control panel that mimics the control panel of a diesel locomotive -- You can even blow the horn, Campbell said -- and are both more efficient and less hazardous than manned locomotives. http://www.computerworld.com/mobiletopics/mobile/story/0,10801,87322,00.html ?f=x68 So at least we know one place not to take the WiFi-enabled horde that is the IETF road-show! Then again...vbg /gordon
Re: Rf Id tag protocol
The purpose of the protocol is to manage over the internet the information stored in a RF-ID tag. More in detail the idea is to develop a crittography system and a certification authority. To encrypt the data stored into the tag will be necessary to prevent frauds on the tagged products. The purpose of the protocol is to manage over the internet the information stored in a RF-ID tag. More in detail the idea is to develop a crittography system and a certification authority. giuseppe canale
RE: Rf Id tag protocol
Besides what Bill Manning said about reviewing what's been done in the auto-id center (now closed), there are a number of research projects/initiatives around the world (e.g., Japan's ubiquitous id center at uidcenter.org). For a list of some related resources, see: http://www.itu.int/osg/spu/newslog/stories/2003/06/06/ubiquitousNetworksReso urces.html There's plenty of debate about whether the public Internet is an appropriate platform, e.g., see http://tronweb.super-nova.co.jp/autoidvubiqid.html Bob -Original Message- From: escom [mailto:[EMAIL PROTECTED] Sent: 20 November 2003 13:18 To: [EMAIL PROTECTED] Subject: Re: Rf Id tag protocol The purpose of the protocol is to manage over the internet the information stored in a RF-ID tag. More in detail the idea is to develop a crittography system and a certification authority. To encrypt the data stored into the tag will be necessary to prevent frauds on the tagged products. The purpose of the protocol is to manage over the internet the information stored in a RF-ID tag. More in detail the idea is to develop a crittography system and a certification authority. giuseppe canale
Re: i18n name badges
JORDI PALET MARTINEZ wrote: It should be RFID, cheaper, and easier, not only for the blue sheets. How would RFID be cheaper than barcodes? Someday, maybe, but today the tags are expensive--according to CNet, depending on volume, customers can expect to pay 30 cents to $1 per radio tag. The IETF would be low-volume, so we'd probably be paying closer to $1 apiece. So just the tags for just one meeting would cost more than a passel of barcode scanners. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |A successful tool is one that was used to do something undreamed| |of by its author. | \/
Re: i18n name badges
Dave Crocker wrote: What I would suggest, if we do this, is writing the person's name *twice*: once in their native character set, and once in a form that an english-reader can read. The latter is an established interchange architecture I believe that was the intention in the proposal. List names in the same way we always have, AND list them in their native form. Whether it would helpful to provide a third form -- the ascii encoding of the native form, as it would be seen in an email address header -- is a separate question. It seems to me that this is really the heart of the matter. There are too many encodings. There are going to be *at least* three desirable encodings of a person's identity -- the 'natural' encoding in the preferred/native charset of the person's name, some kind of phonetic-ASCII encoding that tells non-natives how to pronounce the name, and the email/idna encoding[s] that folks would use to exchange mail. Of the two 'name' forms, it might be possible for the protocol to choose just one encoding based on the meeting context. For example, if the meeting attendees are entirely (or mostly) native speakers of the same language, then use the natural encoding for the names and just ignore the phonetic ASCII entirely. If the meeting is heavily internationalized, then the phonetic form is needed and the natural forms are less useful and can be dropped. So, I would think that part of the protocol should look at trying to determine the meeting context, choose the appropriate encoding, and drop the other (contextually inappropriate) name representation. I think that the default case for IETF meetings would probably be the phonetic ASCII representation given the constituency, but the protocol should still attempt to deliver on the right context even when we know what the context will be for these particular meetings. I would also suggest that if the meeting context is determined to be mostly local, and the name is determined to use a natural encoding, then any contact (email) data should also be provided in that encoding, since it will be memorable to people who can understand the name context. If the meeting context is mixed-international, then an ASCII representation should be used. Whether or not the ASCII representation is IDNA or a phonetic (pre-IDNA) address is up to the the person who provides that data. Also, the designers should remember that there will be some cases where meetings that prefer natural encodings will still have phonetic contact addresses (pre-IDNA, again). If done correctly, there would only need to be the two identifiers, and they would only need to be provided in a single encoding each, determined by the context of the specific meeting itself. -- Eric A. Hallhttp://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
RE: i18n name badges
Actually, I think RFID is much more expensive than bar codes, and it's even more expensive the more you use it. With barcode, you pay once for the readers. Printing barcodes on badges doesn't cost anything. RFID tags cost money every time you make a badge, plus the readers are what, 10X the cost of a barcode reader now? RFID tags with storage are currently pretty expensive, and unnecessary, IMO. Just a unique serial number and the registration database is sufficient. I think we can make both optional. Barcode is easily optional, just don't swipe in. I think you can easily lower the range of RFID so that accidental swiping isn't likely. You can also just decline to get the barcode or RFID tag. Brian -Original Message- From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 4:28 PM To: [EMAIL PROTECTED] Subject: Re: i18n name badges It should be RFID, cheaper, and easier, not only for the blue sheets. The badge could be pre-configured with the data from our own IETF registration. The badge will store the names of the people who we have been talking during the week, and data like when, how much time, We can then use an inexpensive reader to get a small database out of it. Someone can complain about privacy issues, but I feel that is the same now when the blue sheet is circulated, or the attendance list is in the web site, right ? It will save a lot of time (money) to all of us, including the IETF secretariat. Regards, Jordi - Original Message - From: Rosen, Brian [EMAIL PROTECTED] To: 'JORDI PALET MARTINEZ' [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 10:14 PM Subject: RE: i18n name badges Let's keep going. I'd contribute, say, $25, plus write some code towards getting a barcode reader (or, maybe RFID??) for each meeting room that would be used to swipe in and automate the blue sheets. Brian -Original Message- From: JORDI PALET MARTINEZ [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 3:08 PM To: [EMAIL PROTECTED] Subject: Re: i18n name badges Keith, I'm not sure if you are joking, but I think is an excellent idea ... A badge communication protocol ... if you start with the draft, I will be happy to contribute ! Regards, Jordi - Original Message - From: Keith Moore [EMAIL PROTECTED] To: Peter Saint-Andre [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 8:12 PM Subject: Re: i18n name badges Proposals for making email addresses fully internationalized were a hot topic in Minneapolis. I'd like to suggest a more modest reform: fully internationalized IETF name badges. IETF 59 might be a fine venue for rolling those out... I'd love to see an Internet-Draft on the topic. For instance, should the badges be able to list multiple versions of a person's name and affiliation? How many versions? That, and it seems appropriate to demonstrate running code. Set up a web form where an attendee can type in his own names and affiliations and have the backend generate a file to be printed out. ** Madrid 2003 Global IPv6 Summit Presentations and videos on line 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. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]). ** Madrid 2003 Global IPv6 Summit Presentations and videos on line 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. ___ This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by IETF_CENSORED ML Administrator ([EMAIL PROTECTED]).
Re: i18n name badges
On 19-nov-03, at 22:28, JORDI PALET MARTINEZ wrote: It should be RFID, cheaper, and easier, not only for the blue sheets. Wouldn't it be even cheaper if everyone who has a laptop with wireless with them signs in on an electronic version of the blue sheets? This just takes a few hours of fiddling with PHP and saves the secretariat probably 90% of the blue sheet processing.
RFID and EPCglobal
At 08:45 AM 11/20/2003, [EMAIL PROTECTED] wrote: Besides what Bill Manning said about reviewing what's been done in the auto-id center (now closed), there are a number of research projects/initiatives around the world (e.g., Japan's ubiquitous id center at uidcenter.org). For a list of some related resources, see: http://www.itu.int/osg/spu/newslog/stories/2003/06/06/ubiquitousNetworksReso urces.html There's plenty of debate about whether the public Internet is an appropriate platform, e.g., see http://tronweb.super-nova.co.jp/autoidvubiqid.html Bob Bob is right about the auto-id center being closed it has been reshaped into the new http://www.epcglobalinc.org/ http://www.epcglobalinc.org/standards_technology/specifications.html The current focus is on the case-carton-pallet market and not the consumer product itself where there are significant privacy issues at this time. EPCglobal is focusing on the standards though I suspect there are aspects of the protocols being discussed that should come to the IETF or IEEE for proper peer review and/or standardization. There is an extensive discussion of the use of the DNS and NAPTR RR's in the ONS specification. -Original Message- From: escom [mailto:[EMAIL PROTECTED] Sent: 20 November 2003 13:18 To: [EMAIL PROTECTED] Subject: Re: Rf Id tag protocol The purpose of the protocol is to manage over the internet the information stored in a RF-ID tag. More in detail the idea is to develop a crittography system and a certification authority. To encrypt the data stored into the tag will be necessary to prevent frauds on the tagged products. The purpose of the protocol is to manage over the internet the information stored in a RF-ID tag. More in detail the idea is to develop a crittography system and a certification authority. giuseppe canale Richard Shockey, Senior Manager, Strategic Technology Initiatives NeuStar Inc. 46000 Center Oak Plaza - Sterling, VA 20166 sip:rshockey(at)iptel.org ENUM +87810-13313-31331 PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683, Fax: +1 815.333.1237 mailto:richard(at)shockey.us or mailto:richard.shockey(at)neustar.biz http://www.neustar.biz ; http://www.enum.org
Re: RFID and EPCglobal
On Thu, 2003-11-20 at 10:52, Richard Shockey wrote: EPCglobal is focusing on the standards though I suspect there are aspects of the protocols being discussed that should come to the IETF or IEEE for proper peer review and/or standardization. There is an extensive discussion of the use of the DNS and NAPTR RR's in the ONS specification. Being involved in those I can attest to the fact that no one is developing new protocols where they're not needed. So in effect the protocols being used have already been peer reviewed since those protocols were actually developed by other standards bodies -MM
Re: i18n name badges
Iljitsch van Beijnum wrote: On 19-nov-03, at 22:28, JORDI PALET MARTINEZ wrote: It should be RFID, cheaper, and easier, not only for the blue sheets. Wouldn't it be even cheaper if everyone who has a laptop with wireless with them signs in on an electronic version of the blue sheets? This just takes a few hours of fiddling with PHP and saves the secretariat probably 90% of the blue sheet processing. But would people do it? As it is now, the blue sheet comes around and you sign it; done. If the chair stood up and said, Remember to sign in at ietf.org/bluesheet, people would put it off until it was convenient, and many would forget. If we want to reduce the cost of processing the blue sheets, we could provide each attendee with a sheet of barcode stickers. The bluesheet comes around, you put one of your stickers on it, you pass it on. Then the secretariat needs just one barcode scanner, and can probably get done faster than it takes to do data entry on the current bluesheets. The barcodes would have unique IDs; the secretariat would print up a couple thousand in advance of a meeting and save the unused ones for the next meeting. When someone registered on-site, the registration process would include scanning one of their barcodes, to build the link between barcode and name. A quick search at Amazon shows address labels, 25 sheets of 30, for $10. Give each attendee one sheet; that's 40 cents per person. Less than RFID, we only need one reader, and barcode readers are cheap. Or somebody could hack up software to do barcode recognition on the image of the bluesheet, and then the secretariat can use a flatbed scanner and scan a whole sheet at a time. -- /\ |John Stracke |[EMAIL PROTECTED] | |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | || |A successful tool is one that was used to do something undreamed| |of by its author. | \/
Re: i18n name badges
There are going to be *at least* three desirable encodings of a person's identity -- the 'natural' encoding in the preferred/native charset of the person's name, some kind of phonetic-ASCII encoding that tells non-natives how to pronounce the name, and the email/idna encoding[s] that folks would use to exchange mail. Folks: it has *not* been decided that there will be a different encoding for email. One such encoding has been proposed; other proposals have been made. This is being actively discussed, and there should be no assumption that the discussion will end with a new encoding. --Paul Hoffman, Director --Internet Mail Consortium
Re: WLAN's and trains (was: IETF58 - Network Facts_
[EMAIL PROTECTED] wrote: BNSF (Burlington Northern and Santa Fe Railway) has started to deploy Wi-Fi wireless LAN systems extensively in rail yards to allow crews to remotely control engines used to make up trains. These Wi-Fi systems are connected to a control panel that mimics the control panel of a diesel locomotive -- You can even blow the horn, Campbell said -- and are both more efficient and less hazardous than manned locomotives. Thanks, I didn't know about that one. For more on WLAN and trains, google the following: -NetSeal Avecra (in-train restauration's cashier syncs with station's mainframe) -Virgin in UK (WLAN hotspots alongside tracks) -GNER in UK -Click TGV in France -PointShot in the Bay Area -last IETF in Japan, train from airport to city. -I think there is a WLAN'ed train in Finland too. So at least we know one place not to take the WiFi-enabled horde that is the IETF road-show! I think IETF'ers went to Japan and tried a WLAN'ed train near Tokio. Alex
howto WLAN, several subnets
Hi, I was not at the last IETF, and couldn't see live the reportedly bad workings of WLAN. I am not going to make suggestions to 58crew since I'm certain they've already tried lots of configurations. Just to share our thoughts on how we make work several independent/deterministic-behaviour 802.11b subnets: -for the general public, set the AP's with both an essid and a key, in Infrastructure mode (managed). -for the aodv public, convene to use a different essid and a different key and ad-hoc mode. If the aodv people need several ad-hoc mode subnets, just set yet another essid+key; of course all essid's and key's must be different each compared to the other. We have experience with several independent/deterministic-behaviour WLAN links set up that way. But, even if this works well with several AP types and cards, there exist cards out there that only support enc at 128bit while others only at 64bit, which makes _any_ use of encryption non-portable. That says, if ietf crew decides to put a key 64bit then there will be people not able to connect. Same if it decides for 128bit. To me, the whole story is a matter of compatibility, backward compatibility and forward compatibility between various versions of the 802.11 standards _and_ of their implementations. It is exactly like with Word versions: it's the same Doc format but not quite depending on the Windows version too. I do not think anyone could be blamed of interfering with a WLAN network, most notably because this is unlicensed spectrum; I presume harmonics of an old microwave oven could be blamed for interference with the ietf wlan as much as a user not knowing his intel laptop has centrino. Alex
Re: howto WLAN, several subnets
what exactly is the point of having a wep key shared by 2000 people. except to have another thing for people to screw up when they try and type it in our paste it. thereby increasing the support overhead at the help desk. joelja On Thu, 20 Nov 2003, Alexandru Petrescu wrote: Hi, I was not at the last IETF, and couldn't see live the reportedly bad workings of WLAN. I am not going to make suggestions to 58crew since I'm certain they've already tried lots of configurations. Just to share our thoughts on how we make work several independent/deterministic-behaviour 802.11b subnets: -for the general public, set the AP's with both an essid and a key, in Infrastructure mode (managed). -for the aodv public, convene to use a different essid and a different key and ad-hoc mode. If the aodv people need several ad-hoc mode subnets, just set yet another essid+key; of course all essid's and key's must be different each compared to the other. We have experience with several independent/deterministic-behaviour WLAN links set up that way. But, even if this works well with several AP types and cards, there exist cards out there that only support enc at 128bit while others only at 64bit, which makes _any_ use of encryption non-portable. That says, if ietf crew decides to put a key 64bit then there will be people not able to connect. Same if it decides for 128bit. To me, the whole story is a matter of compatibility, backward compatibility and forward compatibility between various versions of the 802.11 standards _and_ of their implementations. It is exactly like with Word versions: it's the same Doc format but not quite depending on the Windows version too. I do not think anyone could be blamed of interfering with a WLAN network, most notably because this is unlicensed spectrum; I presume harmonics of an old microwave oven could be blamed for interference with the ietf wlan as much as a user not knowing his intel laptop has centrino. Alex -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
RE: IETF58 - Network Facts
Theodore Ts'o wrote: Would it be possible to publish a list of MAC addresses that were operating in ad-hoc or AP mode? If all of the happened to come from a signle manufacturer, that might be a very interesting data point. A lot -- possibly even a majority -- of the cards I saw operating in ad-hoc mode were using mac address prefixes that aren't assigned to any manufacturer by the IEEE [1]. Many started with the octet C0. I even saw a card in ad-hoc mode with a MAC address of FF:FF:FF::FF:FF:FF. /a [1] According to http://standards.ieee.org/regauth/oui/oui.txt which is updated daily.
Re: howto WLAN, several subnets
Joel Jaeggli wrote: what exactly is the point of having a wep key shared by 2000 people. I didn't mean it for data confidentiality; I meant it for building the wires W in WEP not for the P privacy. Basically one such W for ietf and one for aodv. We've noticed that setting both the essid and the key helps a lot with the automatic detection various procedures, such as end-user laptops don't get automatically attached to essid's that happen to be advertised without keys by other end-users' laptops. except to have another thing for people to screw up when they try and type it in our paste it. thereby increasing the support overhead at the help desk. Yes, I understand that talking in terms of 2000 actual people is different than in terms of 20some hosts we're using. Alex
Re: howto WLAN, several subnets
On Thu, 20 Nov 2003, Alexandru Petrescu wrote: -for the general public, set the AP's with both an essid and a key, in Infrastructure mode (managed). -for the aodv public, convene to use a different essid and a different key and ad-hoc mode. If the aodv people need several ad-hoc mode subnets, just set yet another essid+key; of course all essid's and key's must be different each compared to the other. [...] Exactly what problem is being solved by the introduction of a key? My perception is that it brings more problems than it fixes (as you stated), and gives a wrong sense of security to boot. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: howto WLAN, several subnets
On Thu, 20 Nov 2003, Alexandru Petrescu wrote: Joel Jaeggli wrote: what exactly is the point of having a wep key shared by 2000 people. I didn't mean it for data confidentiality; I meant it for building the wires W in WEP not for the P privacy. Basically one such W for ietf and one for aodv. We've noticed that setting both the essid and the key helps a lot with the automatic detection various procedures, such as end-user laptops don't get automatically attached to essid's that happen to be advertised without keys by other end-users' laptops. I expect you'll get a bounch of nodes in adhoc mode with the ietf5X ssid and the ietf5x wep key as well... except to have another thing for people to screw up when they try and type it in our paste it. thereby increasing the support overhead at the help desk. Yes, I understand that talking in terms of 2000 actual people is different than in terms of 20some hosts we're using. Alex -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: howto WLAN, several subnets
Pekka Savola wrote: On Thu, 20 Nov 2003, Alexandru Petrescu wrote: -for the general public, set the AP's with both an essid and a key, in Infrastructure mode (managed). -for the aodv public, convene to use a different essid and a different key and ad-hoc mode. If the aodv people need several ad-hoc mode subnets, just set yet another essid+key; of course all essid's and key's must be different each compared to the other. [...] Exactly what problem is being solved by the introduction of a key? Maybe, helping to find conceptual wires to attach to in a deterministic manner, not necessarily private. One can not accidentally attach to such a wire without explicitely setting a key. My perception is that it brings more problems than it fixes (as you stated), I stated that if crew decides 128bit then all people having 128bit cards can work ok (and not those with 48bit-exclusively cards). It does not stop an attacker to set his own linux AP with same key and essid ietf, fooling passers by; but at that point that person, if found, _can_ be blamed. and gives a wrong sense of security to boot. I didn't claim security. So, if the use of keys gives a false sense of security and moreover brings overload at the helpdesk, sorry for the proposal, something else must be used. Alex
Re: howto WLAN, several subnets
Joel Jaeggli wrote: We've noticed that setting both the essid and the key helps a lot with the automatic detection various procedures, such as end-user laptops don't get automatically attached to essid's that happen to be advertised without keys by other end-users' laptops. I expect you'll get a bounch of nodes in adhoc mode with the ietf5X ssid and the ietf5x wep key as well... If my node has mode managed it will never attach to laptop nodes having same key same essid but mode ad-hoc. (my linux node, I know not about windows drivers). Alex
Re: howto WLAN, several subnets
On Thu, 20 Nov 2003, Alexandru Petrescu wrote: Joel Jaeggli wrote: We've noticed that setting both the essid and the key helps a lot with the automatic detection various procedures, such as end-user laptops don't get automatically attached to essid's that happen to be advertised without keys by other end-users' laptops. I expect you'll get a bounch of nodes in adhoc mode with the ietf5X ssid and the ietf5x wep key as well... If my node has mode managed it will never attach to laptop nodes having same key same essid but mode ad-hoc. (my linux node, I know not about windows drivers). that's exactly what's happening though... we have very good ideas about whose wireless implementations are doing the right thing. it's the ones that aren't that are the problem. Alex -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2
Re: IETF58 - Network Status
Just want to add that the network worked perfectly for me during the entire IETF, I didn't have any problems at plenary either. Twice in the lobby bar I lost the association with the access point for a short while, but apart from that... I used 802.11b most of the time. I don't know if I'm exceptional or if it's just that only people with problems are posting... For me this was one of the better wireless IETFs, with Vienna being the best. The most important now is perhaps to start writing down how it should be done, so that the next host has some good advice, and then revise that after next IETF and so on. Stig
RE: IETF58 - Network Facts
Well I was one satisfied customer :-) ---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. Except for some initial hiccups on Monday, and one location (hotel lobby by the reception desk, where I think the hotel was supposed to have turned off their APs, but clearly didn't), I had pretty near flawless connectivity. Regrettably, I was using an OS not known for its reliability. I had built-in wireless too, which I wasn't sure was going to work because of reception issues at another conference. 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 -Vach
unsubscribe
escom wrote: The purpose of the protocol is to manage over the internet the information stored in a RF-ID tag. More in detail the idea is to develop a crittography system and a certification authority. To encrypt the data stored into the tag will be necessary to prevent frauds on the tagged products. The purpose of the protocol is to manage over the internet the information stored in a RF-ID tag. More in detail the idea is to develop a crittography system and a certification authority. giuseppe canale
Re: IETF58 - Network Status
Kevin C. Almeroth wrote: It might be a good idea to stop comparing Minneapolis to Vienna. Vienna had a host and Minneapolis did not. I'm not sure there should be any difference. I was the host in Adelaide but I didn't do the radios, I out sourced them to a local company that specialises in that sort of stuff. They were interested in seeing a large deployment of radios and understanding the problems encountered. Perhaps we should be targeting these sort of companies to help us? Mark.
Re: howto WLAN, several subnets
-BEGIN PGP SIGNED MESSAGE- Alexandru == Alexandru Petrescu [EMAIL PROTECTED] writes: Alexandru Joel Jaeggli wrote: what exactly is the point of having a wep key shared by 2000 people. Alexandru I didn't mean it for data confidentiality; I meant it for Alexandru building the Alexandru wires W in WEP not for the P privacy. Basically one such W Alexandru for ietf and Alexandru one for aodv. Why do you think that the helpful drivers that kept us coming up in IBSS mode (proper name for new ad-hoc mode) won't use the keys as well? Further, as was said, it does nothing against malicious rogue APs? ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP71Qq4qHRg3pndX9AQH37QP+IdXat9qKozC8eq7sgvr0IIrKE1E+0je8 +VAByQ6CnWPj3g9dzuL/lj7A7x14S2Qvv0UF7bcv9qRCGxz1QrF1Egw41oNzv/Ro gWh0FEjPkbc+4itFRqVzFmO5YxSY93v2QPHuYLZgzDPmq+98NaZxtNWo3LbJb5Dj w7rQGUslLIc= =e4MB -END PGP SIGNATURE-
Re: howto WLAN, several subnets
-BEGIN PGP SIGNED MESSAGE- Alexandru == Alexandru Petrescu [EMAIL PROTECTED] writes: Alexandru If my node has mode managed it will never attach to laptop Alexandru nodes Alexandru having same key same essid but mode ad-hoc. No, that's isn't true. It is true for: ad-hoc = Lucent Ad-HOC mode (deprecated) but not true for: ad-hoc = 802.11 IBSS mode In fact, the client can't tell the difference between IBSS and BSS. Nor can Linux systems become IBSS systems without something like hostap ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[ ] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic(Just another Debian GNU/Linux using, kernel hacking, security guy); [ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBP71RVYqHRg3pndX9AQHgqAP/cMNuKQpXOyheLXHeg3RFJEa3usyT0ZyS c7y2qKkdmuTwZEDIAkt1hc2l62G91+aFDzQbx/3OYQhqG9I+4yXz3e2UnMe4btGh RMJQnxYrfv1EyrY4fGcsiCN2qRcuJ3KyNrkrRDRnfW0Fw/t9LsRALEfcsR/NGbog TAEnhWQp5t4= =qHj+ -END PGP SIGNATURE-
Re: IETF58 - Network Status
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stig Venaas wrote: | Just want to add that the network worked perfectly for me during the | entire IETF, I didn't have any problems at plenary either. Mee to. I even had good reception in my room at the doubletree. leifj -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/vW7r8Jx8FtbMZncRAtJZAJ94JN+mjew9NdpmB/IPxZb2uzlxkQCfSwVW 07BOt7eJdtQkoJwGp1gmy9Q= =xavr -END PGP SIGNATURE-
Re: IETF58 - Network Facts
In message [EMAIL PROTECTED] com, Adam Roach writes: Theodore Ts'o wrote: Would it be possible to publish a list of MAC addresses that were operating in ad-hoc or AP mode? If all of the happened to come from a signle manufacturer, that might be a very interesting data point. A lot -- possibly even a majority -- of the cards I saw operating in ad-hoc mode were using mac address prefixes that aren't assigned to any manufacturer by the IEEE [1]. Many started with the octet C0. I even saw a card in ad-hoc mode with a MAC address of FF:FF:FF::FF:FF:FF. I saw some unicast TCP packets sent to MAC address FF:FF:FF::FF:FF:FF -- I have no idea how that happened... --Steve Bellovin, http://www.research.att.com/~smb
Re: IETF58 - Network Facts
Is that 11xx as in local group address or xx00 as in universal unicast? Tom Petch -Original Message- From: Adam Roach [EMAIL PROTECTED] To: 'Theodore Ts'o' [EMAIL PROTECTED]; Brett Thorson [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]; [EMAIL PROTECTED] [EMAIL PROTECTED] Date: 20 November 2003 17:23 Subject: RE: IETF58 - Network Facts Theodore Ts'o wrote: Would it be possible to publish a list of MAC addresses that were operating in ad-hoc or AP mode? If all of the happened to come from a signle manufacturer, that might be a very interesting data point. A lot -- possibly even a majority -- of the cards I saw operating in ad-hoc mode were using mac address prefixes that aren't assigned to any manufacturer by the IEEE [1]. Many started with the octet C0. I even saw a card in ad-hoc mode with a MAC address of FF:FF:FF::FF:FF:FF.
RE: IAB Response to Tony Hain's appeal of October 9, 2003
I appreciate the prompt response. A few points of clarification: The contention was that there was no WG decision, because there was no consistent technical basis for the question. It is impossible to judge 'correctness' without some defining scope. When the responsible AD Chair use clarifications of 'somewhere to the left' and 'handwave', it should be obvious that someone needs to go back and write a concrete definition for what is being discussed before any conclusions can be drawn. I was only aware of one question from the IESG on 8/1, which I responded to that day. I have no idea why the IESG would claim they were unsuccessful in their attempt to seek clarification. The IAB's role here (and IESG for that matter) is to ensure that the leadership has not endorsed or participated in an edict of 'the correct technical decision' outside of the proper process. My understanding of the IESG response was that it didn't matter how the WG got here, they were happy with the result. If the IAB's interpretation of the language and question scope (sec 4.6) had been the clear interpretation from the participants in the SF meeting mail list, I would not have bothered with the appeal process. Given the context of the interpretation as specific to the prefix FEC0::, I consider the matter closed. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leslie Daigle Sent: Monday, November 17, 2003 12:55 PM To: IETF-Announce: Subject: IAB Response to Tony Hain's appeal of October 9, 2003 IAB Response to Appeal from Tony Hain On October 9, 2003, the IAB received an appeal against the IESG decision regarding the IPv6 Working Group chairs' declaration of consensus on the issue of site local addresses in the IPv6 address architecture (Attachment A). 1. The Appeal Question The IAB interpreted this appeal to be as follows: The appeal is that the IESG, in upholding the IPv6 Working Group chairs' and Internet Area ADs' decisions relating to the declaration of consensus on the issue of deprecation of site local addresses in the IPv6 address architecture, made an incorrect decision. 2. The Basis of the Appeal The appeal is using the process described in Section 6.5.2 of the Internet Standards Process (RFC 2026), namely: Should the complainant not be satisfied with the outcome of the IESG review, an appeal may be lodged to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing and report to the IETF on the outcome of its review. If circumstances warrant, the IAB may direct that an IESG decision be annulled, and the situation shall then be as it was before the IESG decision was taken. The IAB may also recommend an action to the IESG, or make such other recommendations as it deems fit. The IAB may not, however, pre-empt the role of the IESG by issuing a decision which only the IESG is empowered to make. The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed. 3. The Process used by the IAB to Review the Situation The question raised by the appeal from the perspective of the IAB is whether the Internet Standards Process been followed in the determination of Working Group consensus and the subsequent appeal- based reviews on the issue of deprecation of site local addresses in the IPv6 address architecture. The procedure used by the IAB in responding to this appeal has included - review of the documentation of the IETF's standards procedures and a working group's declaration of consensus, as described in RFC 2026 and RFC 2418, - review of the history of this appeal, and the process used and evidence gathered by the IESG in responding to the appeal directed to the IESG, - review of the video recording of the meeting of the IPv6 working group at the 56th IETF, where the original question concerning site local addresses was put to the working group, and - review of the IPv6 Working Group mailing list following the 56th IETF to ascertain what followup actions were taken within the Working Group leading to the declaration of Working Group consensus on this topic, and - review of email on the thread Appeal to the IAB on the site-local issue on the IETF mailing list. 4. IAB
Re: IETF58 - Network Status
Wednesday 19 November 2003, Stig wrote: Just want to add that the network worked perfectly for me during the entire IETF, I didn't have any problems at plenary either. Twice in the lobby bar I lost the association with the access point for a short while, but apart from that... I used 802.11b most of the time. Ditto to all of the above. Linux/Debian with Aironet 340. Henrik
