<html>
<font size=3>We can turn on security on more (all?) of the rooms, and
come up with a way for the scheduling folks to set up the APIs.
<br><br>
And hey, if doing this would get you to write an AGDP on it all the
better :-).<br><br>
Are you submitting an AGDP document on beer selection?<br><br>
--bob<br><br>
At 12:59 PM 1/28/2002 -0700, Don Morton wrote:<br>
<blockquote type=cite class=cite cite>Well, as I think about it, this
idea of passing keys around before<br>
a secure meeting seems a WHOLE lot simpler than trying to come<br>
up with some patchwork integrative approach :)<br><br>
I see on the Reservations page that secure rooms are available by<br>
special request, and there's some mention of needing to provide <br>
venues logins, which makes sense. I wonder if it might be
more<br>
efficient to streamline the reservation of the existing secure<br>
rooms, with some documentation. Right now, I'm not clear on
exactly<br>
how we'd make reservations and then, how we'd access the secure<br>
room (though I suspect it's intuitive). And, hell, I'd be willing
to do<br>
an AGDP document on it :)<br><br>
Thanks,<br><br>
DOn<br><br>
Rick Stevens wrote:<br>
> <br>
> Don,<br>
> <br>
> We have been thinking about how to implement a generallized
access<br>
> control mecahnism. Maybe Bob can talk about current thinking
in<br>
> that direction.. in the mean time the secure room avoids this by
using<br>
> the key distribution as an ad hoc access control. We can build
as many<br>
> secure rooms as we need until we have the automatic access control
in<br>
> place.<br>
> <br>
> --Rick<br>
> <br>
> On Mon, 28 Jan 2002, Don Morton wrote:<br>
> <br>
> > All,<br>
> ><br>
> > As some of you have probably noticed, it's getting harder and
harder<br>
> > to have a semi-confidential meeting in one of the venues (e.g.
proposal<br>
> > related stuff) without having one or two sites sitting in there
with<br>
> > 4 videos, audio turned on, sometimes even testing audio in the
middle<br>
> > of a meeting. Although appeals to the community at large
probably help<br>
> > to reduce this, it ain't working, and my uneducated guess
suggests it<br>
> > will get worse - it seems like more and more, folks are jumping
in<br>
> > who seem unaware of things like this mailing list, the
general<br>
> > AG community, etc.<br>
> ><br>
> > So, is there any sort of thought/interest in some mechanism
that allows<br>
> > someone who's actually reserved a venue to control access to
that venue<br>
> > during the time reserved? For example, consider the
following:<br>
> ><br>
> > - Joe/Jane Sixpack makes a venues reservation on behalf of
whatever group<br>
> > wants to come together and meet<br>
> ><br>
> > - Joe/Jane Sixpack (you can tell we're still thinking about
this Beer<br>
> > Symposium :) :)) is automagically emailed some
random access code that's<br>
> > good during the event<br>
> ><br>
> > - This access code allows Joe/Jane Sixpack access to some GUI
that essentially<br>
> > allows for blocking out the "riff raff"
:) :) :)<br>
> ><br>
> > Obviously, it's "do-able" but I don't understand the
venues system well enough<br>
> > to<br>
> > understand the feasibility of integration into existing
components - probably a<br>
> > real bear.....<br>
> ><br>
> > Thanks!!<br>
> ><br>
> > Don<br>
> > --<br>
> > Don
Morton
<a href="http://mroccs.cs.umt.edu/~morton/" eudora="autourl">http://MRoCCS.cs.umt.edu/~morton/</a><br>
> > Department of Computer
Science The University of
Montana<br>
> > Missoula, MT 59812 | Voice (406) 243-4975 | Fax (406)
243-5139<br>
> ><br>
> ><br><br>
<br>
-- <br>
Don
Morton
<a href="http://mroccs.cs.umt.edu/~morton/" eudora="autourl">http://MRoCCS.cs.umt.edu/~morton/</a><br>
Department of Computer Science The
University of Montana<br>
Missoula, MT 59812 | Voice (406) 243-4975 | Fax (406)
243-5139</font></blockquote></html>