I agree with Steve that we should look at the issues that arise, then deal with each in turn. Let me say up front that I am sure our hosts are offering this technology demo with an honorable intent, so we should in turn have a respectful discussion of the issues. I suspect the announced placement and handling of readers will have a significant impact on the participation rate. I was a speaker at an event a few years back that used an rfid reader system, where the readers tracked entry and exit times from each meeting room, as well as harvesting the badge proximity sensors which tracked each other and relative position in the building. I am not suggesting the offered demo has these capabilities, just noting that they do exist. While the announced functionality of the old non-IETF demo was to act as an e-business card for information sharing between the participants, as well as verification of payment for access to each session, the organizer had a much different data mining intent which was clear to those who knew of his other sleazy dealings. Somehow my reader was always forgotten in my room, but since I was a speaker they had to let me in anyway. At the end of the day, knowing the distance between people along with the period of time and where in the facility they were provides a lot of information to people with nefarious intent. Clearly from the discussion about aiding remote participation there is an intent to have a reader at each mic, and something related to the bluesheet clipboard. If it is clear that those are the only readers, and the badges don't track each other there is likely to be a higher level of participation than there would be for an unstated set, or a full mesh tracking system. One issue that comes to mind is the distance between the reader and badge for this to work. Physical contact or a swipe would make the mic line awkward and highlight who was participating and not, while anything more than about 25cm would unintentionally register the person who stepped in the door to look for someone just as the clipboard passed by. I don't know how much control they have over reader sensitivity, but the placement issue should be resolved and announced well in advance of the meeting. As far as data & retention policy, I would suggest that the only data associated directly with the tag be the name, then use an out-of-band means to allow each person to provide whatever other information they are willing to share, including email aliases for each working group. If one use is bluesheet emulation, then the backend can do the correlation to create the logical equivalent. If another use is real-time mic announcement, the data associated with that should be destroyed as soon as the wg minute taker has published. I am sure other functionality is possible, but each should be considered in terms of data retention and possible misuse when the access controls break down (as they will at some point). Tony Steve Crocker wrote: > I won't be in Hiroshima and won't be able to participate nor will I be > able to opt-out, so I don't have a personal stake in this and am > commenting only as an interested observer. > > As has been noted, this won't be an absolutely clean, seamless > replacement of the blue sheets. The list of possible downsides is > already growing, e.g. privacy issues, inflexibility in choosing which > email address to use for each working group, and I won't be surprised > if the list grows a bit. At the same time, the list of possible new > capabilities is also growing, e.g. identifying the speaking at the > microphone. > > This sort of discussion is similar to other settings that are > introducing electronic versions of previously manual processes, e.g. > in the health care industry. Let me offer a point of view and a > suggestion. > > Point of view: Rather than thinking of the RFID chips as serving to be > simply a direct replacement of the blue sheets, take as a given that > this will be a new and somewhat different technical foundation with > some positives and some negatives. The blue sheets also had positives > and negatives, e.g. the cost and pain of storing them, the difficulty > and cost of reading them, their legal status and retention policy, > etc. Look at the RFID chips from a fresh perspective, not solely as > an automation of the blue sheets. > > Suggestion: As noted above, similar issues apply in other settings. > This community has an opportunity to tackle the interplay of > technology and social policy issues that affect itself far more > cogently and efficiently than most communities do. Let's grasp the > nettles and see if we can work through the issues in a sensible and > rational way. Do we need a privacy policy regarding the information > collected? If so, let's create one. Do we need access controls on > the information? If so, let's create them. Do we need an ability to > edit information that's been collected if it's inaccurate? If so, > let's build it. Do we need more flexibility in the information stored > in the record, e.g. a distinct email address for each working group? > If so, let's add it. > > Steve > > > > > > > > On Aug 31, 2009, at 12:27 PM, Paul Hoffman wrote: > > > At 5:55 AM -0700 8/31/09, Alexa Morris wrote: > >> The data collected consist solely of an individuals full name and > >> company/organization affiliation. We are not collecting email > >> address information on the e-blue sheets. > > > > Please note that you are now also collecting information that *is > > not* on the current blue sheets, namely "company/organization > > affiliation". I have noted that some people I know who have signed a > > blue sheet before me have used personal email addresses while (I > > assume) their badge lists their actual "company/organization > > affiliation". As a person with multiple company/organization > > affiliations, I sometimes change the email address I put on the blue > > sheets to be the one most appropriate to the topic of the WG. > > > > It is a bad idea to have this experiment create combined blue sheets > > that have data that differs depending on the collection method. > > There are probably a dozen WGs in the IETF who have had this problem > > come back and bite them on their collective backsides during > > protocol development or, unfortunately, after their protocols have > > deployed. > > > > Please strongly consider having the readers record exactly what the > > current blue sheets record, or change the blue sheets to record what > > the readers are recording for this meeting. The first of these two > > will most likely cause less revolt. > > > > --Paul Hoffman, Director > > --VPN Consortium > > _______________________________________________ > > Ietf mailing list > > Ietf@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf