Re: RFC3271 and independance of "cyberspace"

2002-04-30 Thread ggm
> i think people should be free to create and share but that those who wish to > claim rights should not be prevented from doing so. > > vint Claiming rights is different to be able to enforce rights. It would be useful if there was a document which helped clarify the limits to enforcement giv

Re: RFC3271 and independance of "cyberspace"

2002-05-01 Thread ggm
> On Wed, 01 May 2002 15:00:53 +1000, [EMAIL PROTECTED] said: > > a very important thing. For instance, it could assert that the assumed > > state was that information was in the public domain, and resist the move to > > assume all information innately carries enforceable restrictions ab initio.

Re: IETF 54 calendar & fireworks

2002-05-26 Thread ggm
I suspect if you haven't already arranged to stay for the fireworks, your chances of finding accommodation are vanishingly small. I've certainly just been told all the IETF recommended hotels have no vacancies for beyond Friday night. cheers -George -- George Michaelson | APNIC E

why we had wireless problems at IETF

2002-07-17 Thread ggm
A couple of general questions about 802.11 at IETF in Japan 1) is there some aspect of the telecommunications/regulations here in Japan restricting the number of channels for RF use which affected the problem? Did it help or hinder? -This is a 'cannot fix' problem fo

Re: why we had wireless problems at IETF

2002-07-17 Thread ggm
> actually japan has four non-overlapping channels 802.11 channel 1 6 11 14 > whereas the US has only three because their 2.4ghz ism band goes from > 2.4-2.5 and ours goes from 2.4-2.483. some commonwealth countries have > more stringent output regulations than the US or JP but that's not an

Re: (ietf54-noc 1802) Re: why we had wireless problems at IETF

2002-07-17 Thread ggm
> >the accompaning issues is more than 60-100 clients per ap (and ~200=death) > >really results in reduced performance as well, particulallry if most of > >them are active so more ap's can result in better localized performance, > >assuming you get a handle on the rf issue. > > maybe at I