Anybody else observed that bigben gained about 19 years at about 1:25pm
this arvo?
$ date
Tue Jan 1 14:54:33 NZDT 2002
$ /usr/sbin/ntpdate -q truechimer.waikato.ac.nz
server 130.217.76.32, stratum 2, offset -0.001089, delay 0.04276
1 Jan 14:49:38 ntpdate[17537]: adjust time server 130.217.76.32 offset
-0.001089 sec
$ /usr/sbin/ntpdate -q bigben.clix.net.nz
server 203.167.224.60, stratum 1, offset 619315199.998172, delay 0.03613
1 Jan 14:49:55 ntpdate[17540]: step time server 203.167.224.60 offset
619315199.998172 sec
-
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Roger De Salis sent this to the list:
- - - - -
The Netforum conference for 2003 is scheduled for July 10,11,12.
The Theme of the conference is
Next Generation Internet: Advanced Network Operations
and
Computer Networking in Aviation
The conference will be extremely technical with >2/3 content devoted to advanced networking and related topics.
Speakers are invited to submit proposals for papers to the conference committee by sending a synopsis and Title to "netforum(a)fx.net.nz".
We look forward to an expanded conference in 2003, and the conference committee will be working very hard to meet or exceed the standard set by the 2002 conference, which I hope many of you enjoyed.
The committee looks forward to receiving proposals.
====================================================================
In a similar manner, attendees are welcome to suggest topics or papers they are interested in seeing, and the conference organisers will then be able to help persuade likely speakersto stump up a talk. Send to "suggestions(a)fx.net.nz"
Rgds Roger De Salis
------------------------------------------------------------------------------
"This communication, including any attachments, is confidential.
If you are not the intended recipient, you should not read
it - please contact me immediately, destroy it, and do not
copy or use any part of this communication or disclose
anything about it. Thank you."
------------------------------------------------------------------------------
Hi all, the Redhat mirror server ftp.wicks.co.nz ( ftp.isl.net.nz ) now has
the Sendmail updates. Infact it just synced up the updates for Redhat 9.0,
which is a bit ironic as 9.0 is not even released yet.
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> >
> > CERT Advisory CA-2003-12 Buffer Overflow in Sendmail
> >
> > Original release date: March 29, 2003
> > Last revised:
> > Source: CERT/CC
> >
> > A complete revision history can be found at the end of this file.
> >
> > Systems Affected
> >
> > * Sendmail Pro (all versions)
> > * Sendmail Switch 2.1 prior to 2.1.6
> > * Sendmail Switch 2.2 prior to 2.2.6
> > * Sendmail Switch 3.0 prior to 3.0.4
> > * Sendmail for NT 2.X prior to 2.6.3
> > * Sendmail for NT 3.0 prior to 3.0.4
> > * Systems running open-source sendmail versions prior
> to 8.12.9,
> > including UNIX and Linux systems
> >
> > Overview
> >
> > There is a vulnerability in sendmail that can be exploited
> to cause a
> > denial-of-service condition and could allow a remote
> attacker to
> > execute arbitrary code with the privileges of the
> sendmail daemon,
> > typically root.
> >
> > I. Description
> >
> > There is a remotely exploitable vulnerability in sendmail
> that could
> > allow an attacker to gain control of a vulnerable
> sendmail server.
> > Address parsing code in sendmail does not adequately check
> the length
> > of email addresses. An email message with a specially
> crafted address
> > could trigger a stack overflow. This vulnerability was
> discovered by
> > Michal Zalewski.
> >
> > This vulnerability is different than the one described in CA-2003-07.
> >
> > Most organizations have a variety of mail transfer agents
> (MTAs) at
> > various locations within their network, with at least one
> exposed to
> > the Internet. Since sendmail is the most popular
> MTA, most
> > medium-sized to large organizations are likely to have at
> least one
> > vulnerable sendmail server. In addition, many UNIX
> and Linux
> > workstations provide a sendmail implementation that is
> enabled and
> > running by default.
> >
> > This vulnerability is message-oriented as
> opposed to
> > connection-oriented. That means that the vulnerability is
> triggered by
> > the contents of a specially-crafted email message
> rather than by
> > lower-level network traffic. This is important because
> an MTA that
> > does not contain the vulnerability will pass the
> malicious message
> > along to other MTAs that may be protected at the network
> level. In
> > other words, vulnerable sendmail servers on the interior of
> a network
> > are still at risk, even if the site's border MTA uses
> software other
> > than sendmail. Also, messages capable of exploiting this
> vulnerability
> > may pass undetected through many common packet filters or firewalls.
> >
> > This vulnerability has been successfully exploited to
> cause a
> > denial-of-service condition in a laboratory
> environment. It is
> > possible that this vulnerability could be used to execute
> code on some
> > vulnerable systems.
> >
> > The CERT/CC is tracking this issue as VU#897604. This
> reference number
> > corresponds to CVE candidate CAN-2003-0161.
> >
> > For more information, please see
> >
> > http://www.sendmail.org
> > http://www.sendmail.org/8.12.9.html
> > http://www.sendmail.com/security/
> >
> > For the latest information about this vulnerability,
> including the
> > most recent vendor information, please see
> >
> > http://www.kb.cert.org/vuls/id/897604
> >
> > This vulnerability is distinct from VU#398025.
> >
> > II. Impact
> >
> > Successful exploitation of this vulnerability may
> cause a
> > denial-of-service condition or allow an attacker to
> gain the
> > privileges of the sendmail daemon, typically root. Even
> vulnerable
> > sendmail servers on the interior of a given network may
> be at risk
> > since the vulnerability is triggered by the contents of a
> malicious
> > email message.
> >
> > III. Solution
> >
> > Apply a patch from Sendmail, Inc.
> >
> > Sendmail has produced patches for versions 8.9, 8.10, 8.11,
> and 8.12.
> > However, the vulnerability also exists in earlier
> versions of the
> > code; therefore, site administrators using an earlier
> version are
> > encouraged to upgrade to 8.12.9. These patches, and a
> signature file,
> > are located at
> >
> > ftp://ftp.sendmail.org/pub/sendmail/prescan.tar.gz.uu
> > ftp://ftp.sendmail.org/pub/sendmail/prescan.tar.gz.uu.asc
> >
> > Apply a patch from your vendor
> >
> > Many vendors include vulnerable sendmail servers as
> part of their
> > software distributions. We have notified vendors of this
> vulnerability
> > and recorded the statements they provided in Appendix
> A of this
> > advisory. The most recent vendor information can be
> found in the
> > systems affected section of VU#897604.
> >
> > Enable the RunAsUser option
> >
> > There is no known workaround for this vulnerability. Until a
> patch can
> > be applied, you may wish to set the RunAsUser option to
> reduce the
> > impact of this vulnerability. As a good general practice,
> the CERT/CC
> > recommends limiting the privileges of an application
> or service
> > whenever possible.
> >
> > Appendix A. - Vendor Information
> >
> > This appendix contains information provided by vendors
> for this
> > advisory. As vendors report new information to the
> CERT/CC, we will
> > update this section and note the changes in our revision
> history. If a
> > particular vendor is not listed below, we have not
> received their
> > comments.
> >
> > Red Hat Inc.
> >
> > Red Hat distributes sendmail in all Red Hat Linux
> distributions. We
> > are currently [Mar29] working on producing errata packages
> to correct
> > this issue, when complete these will be available
> along with our
> > advisory at the URL below. At the same time users of
> the Red Hat
> > Network will be able to update their systems using the
> 'up2date' tool.
> >
> > Red Hat Linux:
> >
> > http://rhn.redhat.com/errata/RHSA-2003-120.html
> >
> > Red Hat Enterprise Linux:
> >
> > http://rhn.redhat.com/errata/RHSA-2003-121.html
> >
> > The Sendmail Consortium
> >
> > The Sendmail Consortium recommends that sites upgrade
> to 8.12.9
> > whenever possible. Alternatively, patches are available for
> 8.9, 8.10,
> > 8.11, and 8.12 on http://www.sendmail.org/.
> >
> > Sendmail, Inc.
> >
> > All commercial releases including Sendmail Switch,
> Sendmail Advanced
> > Message Server (which includes the Sendmail Switch MTA),
> Sendmail for
> > NT, and Sendmail Pro are affected by this issue. Patch
> information is
> > available at http://www.sendmail.com/security/.
> > _________________________________________________________________
> >
> > Our thanks to Eric Allman, Claus Assmann, Greg
> Shapiro, and Dave
> > Anderson of Sendmail for reporting this problem and
> for their
> > assistance in coordinating the response to this problem. We
> also thank
> > Michal Zalewski for discovering this vulnerability.
> > _________________________________________________________________
> >
> > Authors: Art Manion and Shawn V. Hernan
> >
> ______________________________________________________________________
> >
> > This document is available from:
> > http://www.cert.org/advisories/CA-2003-12.html
> >
> ______________________________________________________________________
> >
> > CERT/CC Contact Information
> >
> > Email: cert(a)cert.org
> > Phone: +1 412-268-7090 (24-hour hotline)
> > Fax: +1 412-268-6989
> > Postal address:
> > CERT Coordination Center
> > Software Engineering Institute
> > Carnegie Mellon University
> > Pittsburgh PA 15213-3890
> > U.S.A.
> >
> > CERT/CC personnel answer the hotline 08:00-17:00
> EST(GMT-5) /
> > EDT(GMT-4) Monday through Friday; they are on call for
> emergencies
> > during other hours, on U.S. holidays, and on weekends.
> >
> > Using encryption
> >
> > We strongly urge you to encrypt sensitive information sent
> by email.
> > Our public PGP key is available from
> > http://www.cert.org/CERT_PGP.key
> >
> > If you prefer to use DES, please call the CERT
> hotline for more
> > information.
> >
> > Getting security information
> >
> > CERT publications and other security information are
> available from
> > our web site
> > http://www.cert.org/
> >
> > To subscribe to the CERT mailing list for advisories and
> bulletins,
> > send email to majordomo(a)cert.org. Please include in the
> body of your
> > message
> >
> > subscribe cert-advisory
> >
> > * "CERT" and "CERT Coordination Center" are registered
> in the U.S.
> > Patent and Trademark Office.
> >
> ______________________________________________________________________
> >
> > NO WARRANTY
> > Any material furnished by Carnegie Mellon University and
> the Software
> > Engineering Institute is furnished on an "as is"
> basis. Carnegie
> > Mellon University makes no warranties of any kind, either
> expressed or
> > implied as to any matter including, but not limited to,
> warranty of
> > fitness for a particular purpose or merchantability,
> exclusivity or
> > results obtained from use of the material. Carnegie Mellon
> University
> > does not make any warranty of any kind with respect to
> freedom from
> > patent, trademark, or copyright infringement.
> > _________________________________________________________________
> >
> > Conditions for use, disclaimers, and sponsorship information
> >
> > Copyright 2003 Carnegie Mellon University.
> > Revision History
> >
> > March 29,2003: Initial release
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: PGP 6.5.8
> >
> > iQCVAwUBPoX5XGjtSoHZUTs5AQHvjgQAqTy3GQnszPHtUnUBX7VDM4NKSesFHHvC
> > 2JmDAMPYmCO2b32xvWDmMcWdPhOBmJLB2o6zv7mRWX1K0B1GN5TBErIii6dxTaDD
> > OAUNjirMGdTr+WnxIjdk0gj57JbOU6ZdHHcAijG5SE/dZq4sMrOCGEAMJTVNDzYp
> > BtHbFwDeLEY=
> > =dgBI
> > -----END PGP SIGNATURE-----
> >
NZNOG People,
I'd like to make a number of comments about events on this list over the last couple of days. This is partly because I simply don't have the time to respond individually to all of the emails sent to me. Sorry.
But first, a brief chronology of some of this morning's events:
9:03 List notified that mastermithras(a)yahoo.co.nz has been unsubscribed
10:11 List notified that phuct up(a)msn.com has been unsubscribed
10:19 Abusive email with forged From address posted to the list
10:31 "^god" with address god(a)hackers.net.nz subscribes to the list
10:39 Address god(a)hackers.net.nz unsubscribed by administrator
11:00 Notice from Xtra received that originator of abusive email has been
removed from Xtra's network.
All of which makes sense to me, but it's taken us some time to get here. The current AUP process is written to allow a certain amount of stupidity to take place before people get unsubscribed. For myself, I'd prefer to keep it that way.
Complaining to the List
-----------------------
Over the last couple of days, we've seen a considerable number of postings to the list complaining about AUP breaches. I don't mind people emailing me directly, and I certainly don't mind people emailing the senders of such email directly either, but please don't send this sort of thing to the list. It does not seem to influence people who are being intentionally silly, but does swell the volume of non-operational postings.
Moderation
----------
There have been a number of quite understandable suggestions of late that the list should become moderated, if only for a time. I remain unwilling to do this. This is partly to ensure that relevant operational material can be disseminated quickly. It is also because it doesn't look to me possible to square moderation in any circumstances with continuing denial that the administrator is responsible for the content of the list or its archive.
Administration Head Count
-------------------------
The existing process for dealing with idiocy in varying degrees relies on the issuing of warnings. Faster issuing of warnings would result in faster unsubscription of the determinedly anti-social. One way to achieve that would be to move from having a single list administrator to having more than one. Which raises the twin questions of whether there'd be any volunteers for such a role, and "In whom do the people trust?"
- Donald Neal
List Administrator
--
Donald Neal | piano - a musical
Technical Specialist | shipping line.
Network Delivery | [ Graeme Garden ]
Telecom Corp. NZ Ltd |
------------------------------------------------------------------------------
"This communication, including any attachments, is confidential.
If you are not the intended recipient, you should not read
it - please contact me immediately, destroy it, and do not
copy or use any part of this communication or disclose
anything about it. Thank you."
------------------------------------------------------------------------------
Hello all,
I do not trust peer moderation or a pair review process to get on this list.
There is currently a issue going on between two respectable ISP's that
has culminated in mail blocking - A sad state of affiars for the NZ
Internet as I thought we got over this nonsense last century.
(Remember Voyager vs. Xtra?).
I will not name these two ISPs at this point as I respect them both and
I believe that my mail is able to get through although I havn't checked.
To the two ISP's involved I say - You have both been around for
long enough and you are both of a big enough size to sort this out
in an amicable fastion and set a good example for newer and/or
smaller players. I suggest that your relevant management peoples
gets together and sorts the issues out. (That is, if you havn't already).
I do not run an ISP (Although I work part time for one in a technical
role). I run a business selling used high end networking equipment
and setting up Linux systems. I am a one man band here trying to
make an honest living. As I have the skills and inclination, I run
all my own servers (Mail, web etc). My network is used purely by
myself and I have *never* caused anyone any trouble or had any
complaints about how my system is operated. Yet, despite being
an innocent third party, I am caught out by what is going on
higher up in the scheme of things.
C'mon you two, what is the use of a knowledge economy, internet
yada yada etc, if this sort of games are still going on?
No wonder ISP's have the reputation of used car dealers.
(Many of whom have actually cleaned up their act now).
No wonder there is call for ISP's to be "licensed".
http://computerworld.co.nz/webhome.nsf/UNID/DF3A054F76F9698ECC256CE10008E9D…
Best regards to all,
Michael Hallager
Comsolve Networks (NZ) Limited
Networkstuff Limited
In message <20030328020710.GH10265(a)citylink.co.nz>, Simon Blake writes:
>On Fri, Mar 28, 2003 at 01:31:53PM +1200, Donald Neal said:
>> The existing process for dealing with idiocy in varying degrees relies
>> on the issuing of warnings. [....] One achieve that would be to move
>> from having a single list administrator to having more than one. [...]
>
>Rather than moderate the content, why not just close list membership?
>[delete all; add only "genuine NZ network operators"]
I'm not sure if I officially get a say (I probably don't count technically
count as a "genuine NZ network operator"), but I've been around the 'net
a fair while now, and I'm opinionated, so I'm going to have one anyway.
Some points in vague order:
- I know of a bunch of people who are not technically "genuine NZ
network operators" who benefit from reading the list (and more have
posted in this thread) -- "up and coming" people, people loosely
related to network operation who wish to stay "in touch" with what is
going on (I'm probably most accurately in that category), etc.
- For the most part those people get the benefit from reading, rather
than posting to the list; "read only" access might well be sufficient
99% of the time for them.
- Following a list (in "real time") by reading archives on the Interweb
sucks. Screen scraping off the archives of a mailing list that are
on a web page into email again to make it easier to follow is rather
baroque. (But better than trying to follow discussions in real time
on the Interweb; seems 20 years of UI discoveries got thrown out when the
WWW got invented....)
- People who "listen but don't talk" don't create much of a disturbance
to the list operation. There aren't really (m)any secrets where
public knowledge in "real time" would be an issue.
- So if there needs to be moderation (note: I've not yet expressed a
view), then it need only be on the posting side. "Read only"
subscriptions could be left open to "those who can understand the
content" or similar with no obvious downside.
- Moderation of all postings is very disruptive to discussion
particularly of things happening in real time (not to mention a high
load on the moderator(s))
- Therefore it is probably desirable that as few postings as possible
be moderated, without allowing the list to be flooded with large
volumes of off topic stuff.
- The set of people who post (on topic) often is relatively small, and
relatively static, and could probably be maintained by hand by a small
(eg, one person) team of moderators.
- So if there is to be moderation (note: still not expressing a view)
a potentially more workable solution is not to moderate who can join
the list read-only; just to moderate who can post, and "hand moderate"
the remaining posts. People posting a few good posts would be added
to the "can post without additional moderation" list.
Over a short period of time (especially with pre-seeding) those
posting "on topic" messages would get put on the "can post without
additional moderation" list, and that list would be fairly static.
This should be relatively non-intrustrive, and relatively non-demanding
on moderator time.
This basically boils down to Simon (Blake)'s proposal, but with the
restriction being on "posting access" only. The only real catch is
"when good posters go bad", which could perhaps be dealt with in the
same way as now (but with the implicit addition that their newly
invented addresses would not immediately gain posting access).
As to the original question:
- I lean towards the point of view that this has basically been a
one-shot deal and going closed-list/all-moderated/etc over it is
probably an over-reaction. If people would stop feeding the trolls
(even off list) then it'll probably all die a natural death.
- As such I'm not particularly in favour of moderation.
- With a little arm twisting I would be willing to be one of a team of
moderators for the list (on a "if it needs to be done, and no one
else is doing it" basis). I could recite a list of reasons why I'm
qualified, but what it boils down to is that I've been about the NZ
Internet for quite a while, seen my share of flame wars, etc, but don't
work at any network operators so would hopefully be seen as neutral.
(As I said above, I'd rather it wasn't moderated. But if it is, I'm
willing to help out if necessary)
Ewen
for what it's worth I agree with this.
alternatively don't accept list members that have disposable email addresses (hotmail.com, email.com, msn.com, yahoo.co.nz etc etc), or a perverse fascination with bonzai buddy ;-)
jamie
>>> Simon Blake <simon(a)citylink.co.nz> 03/28 2:07 PM >>>
On Fri, Mar 28, 2003 at 01:31:53PM +1200, Donald Neal said:
> The existing process for dealing with idiocy in varying degrees relies
> on the issuing of warnings. Faster issuing of warnings would result in
> faster unsubscription of the determinedly anti-social. One way to
> achieve that would be to move from having a single list administrator
> to having more than one. Which raises the twin questions of whether
> there'd be any volunteers for such a role, and "In whom do the people
> trust?"
Rather than moderate the content, why not just close list membership?
Delete everybody off the list, add back on the people you know are
genuine NZ network operators, and set the list up so that requests to
join get sent to some group of moderators (or to the list). Then, vett
new requests to join through the current members. Leave the web pages
and archives public, so that the world can still read about what we're
up to.
Yes, it's cliquey, yes, it's elitist, but well, who cares. It's the
Network Operators Group - we need to get it a back on topic PDQ,
otherwise it'll cease to have any relevancy to the community it seeks to
serve, and it'll get replaced with something else (that probably will
have a closed membership).
Cheers
Si
> - Donald Neal
> List Administrator
>
> --
> Donald Neal | piano - a musical
> Technical Specialist | shipping line.
> Network Delivery | [ Graeme Garden ]
> Telecom Corp. NZ Ltd |
>
> ------------------------------------------------------------------------------
> "This communication, including any attachments, is confidential.
> If you are not the intended recipient, you should not read
> it - please contact me immediately, destroy it, and do not
> copy or use any part of this communication or disclose
> anything about it. Thank you."
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Nznog mailing list
> Nznog(a)list.waikato.ac.nz
> http://list.waikato.ac.nz/mailman/listinfo/nznog
_______________________________________________
Nznog mailing list
Nznog(a)list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
Simon Lyall [mailto:simon.lyall@ihug.co.nz] wrote:
> I'm a great believer in leaving things alone. Currently we have a
> large number of people on the list who aren't exactly "network
> operators" . The vast majority of these people are no problem and
> don't even post. Some of them will post sometimes when something
> in their area comes up.
I tend to support this view. I'm sure I don't qualify as a "network
operator" by implying a definition from people's posts, but I don't believe
I've been seeding the list with problems, and one or two trouble makers just
need to be dealt with and we move on.
Ironically I suspect more traffic will be created by debating this than was
created by the orignal outburst or the last six months..
IMO. :)
--
David Zanetti <david.zanetti(a)nzpost.co.nz>
Desk: +64-4-496-4005 Mobile: +64-25-832-572
"Hope.. is a dangerous thing"
This email with any attachments is confidential and may be subject to legal
privilege. If it is not intended for you please reply immediately, destroy
it and do not copy, disclose or use it in any way.
On Fri, 28 Mar 2003 14:17, Juha Saarinen wrote:
[SNIP]
> I think you're probably asking a lot of Donald there. So he's to work out
> a definition of what exactly constitutes a NZ network operator (ie.
> network operators from other countries are banned) and then verify who
> exactly fits the definition. How would he do that?
I quite agree. There are many networks in NZ and many operators.
Would op's of internet connected companies qualify or just op's of ISP's?
Would VISP's qualify? Alot of them don't know very much about
operating an Internet network, which is why they are "VISP's", and yet
they should still be welcome here and be able to contribute.
> Also, correct me if I'm wrong, but this is not how NANOG operates. If they
> can handle the occasional outburst of off-topic messages, and I'm sure
> they get more of that on NANOG than on NZNOG, then the participants on
> this list are probably able to do so as well.
I say that this is a knee-jerk reaction to some of Sahil's friends causing
trouble. I vote that we ignore them and continue on as per usual.
> Closing NZNOG would set a bad example, IMO.
There is enough "clubs" and "secret societies" in the world without closing
NZNOG based on the whims and ideals of a few.
The Internet is meant to be a tool of democracy and an open one at that.
Lets keep it that way.
How can we criticise [The NZ closed club of the Internet] if we go and do
the same?
Michael Hallager
Managing Director
Comsolve Networks (NZ) LImited
Networkstuff Limited
-------------------------------------------------------
> Note that I'm basically discussing "rights to post" here. I'm not
>From vague memory, nanog had two levels of subscription (read only, and
read/post).
Maybe the same thing could be done here. Then if they abuse it, shift
people off the read/post list more aggressively than currently is the
case. They don't lose the ability to hear what's going on.
Regards / Ian
-----Original Message-----
From: Simon Blake [mailto:simon@citylink.co.nz]
Sent: Friday, March 28, 2003 3:03 PM
To: Michael Hallager
Cc: nznog(a)list.waikato.ac.nz
Subject: Re: [nznog] Moderation etc.
On Fri, Mar 28, 2003 at 02:32:40PM +1200, Michael Hallager said:
>
> On Fri, 28 Mar 2003 14:17, Juha Saarinen wrote:
>
> [SNIP]
>
> > I think you're probably asking a lot of Donald there. So he's to
work out
> > a definition of what exactly constitutes a NZ network operator (ie.
> > network operators from other countries are banned) and then verify
who
> > exactly fits the definition. How would he do that?
>
> I quite agree. There are many networks in NZ and many operators.
> Would op's of internet connected companies qualify or just op's of
ISP's?
> Would VISP's qualify? Alot of them don't know very much about
> operating an Internet network, which is why they are "VISP's", and yet
> they should still be welcome here and be able to contribute.
Trial by a jury of your peers. If the members of the list know you as
an operator, you get on. If they don't, you don't. There doesn't need
to be any formal defn of what constitutes an operator, merely that the
current members are happy for you to be on the list. In practice, I
imagine this would become "unless you're a really annoying piece of
work, and somebody complains vociferously about your request to join,
you'll get on".
Note that I'm basically discussing "rights to post" here. I'm not
suggesting that the archives shouldn't be public, and if there was a way
to allow Joe Random Public to join readonly without a vetting process,
then that's all good as well.
> > Also, correct me if I'm wrong, but this is not how NANOG operates.
If they
> > can handle the occasional outburst of off-topic messages, and I'm
sure
> > they get more of that on NANOG than on NZNOG, then the participants
on
> > this list are probably able to do so as well.
>
> I say that this is a knee-jerk reaction to some of Sahil's friends
causing
> trouble. I vote that we ignore them and continue on as per usual.
It's been a thought that's occurred to me and others every so often
during at least the last four years. We could ignore them, or we could
try and fix NZNOG to be a better thing, coz at the moment it's broken,
teenagers or no.
> > Closing NZNOG would set a bad example, IMO.
>
> There is enough "clubs" and "secret societies" in the world without
closing
> NZNOG based on the whims and ideals of a few.
So, there are lots of closed lists, so we shouldn't tidy our one?
> The Internet is meant to be a tool of democracy and an open one at
that.
The Internet isn't *meant* to be anything. It just is. I don't believe
that the orginal creators of the 'net had anything to say about its
democratic value. I'm prepared to stand corrected, of course.
There are costs and barriers you must overcome to become a network
operator. Why shouldn't there be a small barrier to you participating
in a network operators list?
> Lets keep it that way.
Sounds like an arguement for untrammelled access to your mailbox by
spammers to me.
> How can we criticise [The NZ closed club of the Internet] if we go and
do
> the same?
I didn't realise that criticism of the "The NZ closed club of the
Internet" was part of NZNOG's role. Maybe that should be put on the
list info pages :-).
Cheers
Si
_______________________________________________
Nznog mailing list
Nznog(a)list.waikato.ac.nz
http://list.waikato.ac.nz/mailman/listinfo/nznog
