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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf