Hi.
Can someone post some details on the outcome of Friday's meeting for
those who could not attend or had to leave early.
Thanks,
-Craig
---------
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
>Can someone post some details on the outcome of Friday's meeting for
>those who could not attend or had to leave early.
The lunch provided by CISCO was absolutely *fantastic* !!
Roger was seen taking orders for lots of kit as a result :-)
regards
Peter Mott
Chief Enthusiast
2Day Internet Limited
http://www.2day.net.nz
-/-
---------
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
On Thu, Nov 19, 1998 at 02:20:54PM +1300, Don Stokes wrote:
> apnic-011 already says that, at least for addresses allocated in
> the NZGate timeframe. I haven't found any other APNIC document
> (expired or not) that states APNIC policy toward address ownership.
Assuming we all follow this then -- do we have allow people or users
with small (eg. /26) networks to take them with them should they
decide to move?
Allowing this _without_ any constraints would make fragmentation
horrific.
> Do you have a clause in your service contracts that states
> explicitly what the position is regarding IP numbers you assign to
> clients? Most ISPs do (and all should).
No idea... I speak only for myself, not for any company. I don't look
at the legal bits where possible, thats what marketroids and legal
people are for.
> Does it matter?
Yes. If someone is allocated address space for which they are not
specifically told whether or not it should be considered portable or
not, and therefore they wish to take the network with them when they
move providers, we could get considerable fragmentation when many
people with small networks do this.
> It does if anyone is allocating address space in new blocks without
> explicitly stating the "ownership" of addresses, but for the old
> addresses it just means that at worst the routing table space taken
> up by old addresses doesn't get any smaller.
I don't follow; surely we have a situation where providers in the
past have carved up a say /20 for clients -- and when a client moves
this /20 might then need to become sixeteen /24 routes (or a /21, a
/22, a /23 and two /24 or whatever).
> It also matters if an ISP wants to move a bunch old /24 prefixes
> over to an upstream provider that refuses to deal with them -- so
> far the ones that have made noises about refusing small netblocks
> this have backed away from that position.
Eventfully as enough /24 are freed up, we will be able to coalesce
adjacent ones into large networks.
> What can be done as a technical group is to develop a consensus on
> how to retire old /24 prefixes and aggregate them into larger
> blocks, either through the APNIC's return policy (apnic-072), or
> through some local arrangement, without grossly impacting on either
> ISP or customer operations.
This seems like a good idea.
> I think the first step in this is to get the "ownership" issues
> aired (I don't think it will be "solved") at the ISOCNZ conference
> tomorrow; at least then hopefully we'll have some idea of what
> various positions are. I don't think the ex-NZGate issue can be
> really proceeded on without that.
Can someone who attends this meeting then please provide some
feedback?
-cw
---------
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
>> A rhetorical question: why does cisco rack mount equipment need a
>> crowbar to install?
I recall a similar problem years ago when in broadcast engineering
environment.
Except in those days the gear worked perfectly on the floor, but when
bolted into that precision peice of engineering known as a rack, it
started to play up.
If you ever did your job really well and tied back the cables neatly so
others could tell you were a professional, it was sure to stop.
Just be thankful that even after your crowbar adjustment, your router
still goes!
regards
Peter Mott
Chief Enthusiast
2Day Internet Limited
http://www.2day.net.nz
-/-
---------
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
A rhetorical question: why does cisco rack mount equipment need a crowbar to install? Would it really be SO difficult to make the cases 2mm narrower so that when the mounting brackets are fitted they slide into the rack rather than having to be forced?
Mild steel is a wonderful engineering material characterised by its ability to gracefully deform under stress, but that doesn't mean I have to enjoy watching it do so.
Mumble.
--
Michael Newbery Technology Manager Saturn Communications
Tel: +64-4-939 5102 Mobile:021-642 957 Fax:+64-4-939 5100
---------
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
[Sorry for the duplicates.]
FYI - for those not on one of the AP* Groups mailing list (APNIC, APIA,
APNG, APPLe, APTLD).
-----Original Message-----
From: owner-apia-board(a)apia.org [mailto:owner-apia-board@apia.org] On
Behalf Of Kilnam Chon
Sent: Thursday, November 26, 1998 8:47 AM
To: apstar(a)apng.org
Subject: [APIA-BOARD] Let's look into icann participation from ap region
ICANN "made" the agreement with NTIA to be recognized.(See NTIA homepage)
ICANN is looking for participation of Membership Advisory Committee, which
is being newly created.(will attach the announcement)
DNSO(and possibly other SOs; ASO, PSO) will look for participation of
various
stakeholders(associations, organizations, individuals,...).(will attach
memos)
Hope to see appropriate participation to various ICANN committees from AP
regions.
my idea is as follows;
1. ICANN Membership Advisory Committee
each relevant AP organizations to volunteer at least one person: apng,
apia,
apple, apricot,...(more)
2. DNSO
APIA for ISP/Telco Constituency
APNG(?) and others for General Business(for- and non-profit)
APNG(?), APRICOT, APPLe,.. for At Large
chon
____________________________________________________________________________
__
>From iana-announce-owner(a)ISI.EDU Thu Nov 26 04:15:01 1998
Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160])
by cosmos.kaist.ac.kr (8.9.1a/8.9.1) with ESMTP id EAA23586
for <chon(a)cosmos.kaist.ac.kr>; Thu, 26 Nov 1998 04:14:58 +0900 (KST)
Received: (from majordom@localhost)
by zephyr.isi.edu (8.8.7/8.8.6) id KAA28440
for iana-announce-outgoing; Wed, 25 Nov 1998 10:08:12 -0800 (PST)
Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128])
by zephyr.isi.edu (8.8.7/8.8.6) with ESMTP id KAA28435
for <iana-announce(a)zephyr.isi.edu>; Wed, 25 Nov 1998 10:08:11 -0800 (PST)
Received: from ode.isi.edu (ode-e.isi.edu [128.9.160.68])
by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id KAA03177;
Wed, 25 Nov 1998 10:08:10 -0800 (PST)
From: Internet Assigned Numbers Authority <iana(a)ISI.EDU>
Received: (from iana@localhost)
by ode.isi.edu (8.8.7/8.8.6) id KAA29487;
Wed, 25 Nov 1998 10:08:09 -0800 (PST)
Date: Wed, 25 Nov 1998 10:08:09 -0800 (PST)
Message-Id: <199811251808.KAA29487(a)ode.isi.edu>
To: iana-announce(a)ISI.EDU
Subject: ICANN Membership Advisory Committee
Cc: iana(a)ISI.EDU
X-Sun-Charset: US-ASCII
Sender: owner-iana-announce(a)ISI.EDU
Precedence: discussion
Status: RO
Content-Length: 3512
Lines: 75
ICANN Membership Advisory Committee-
Expressions of Interest Sought by 5 December, 1998
The ICANN Bylaws call for a membership structure to be established to
elect At Large directors. (See Bylaws Article V, Section 9(c))
The Initial Board is establishing an advisory committee (see Bylaws
Article VII, Section 3(c)) to advise it on the appropriate membership
structure to satisfy the need for world wide representation on the
board, and in particular how to create a diverse and open membership
without subjecting the corporation to undue risk of capture by any
particular interest group. The advisory committee will consist of up
to ten members, and will include Initial Board members George Conrades
as Chairman, and Greg Crew. The Berkman Center for Internet and Society
at Harvard Law School has agreed to provide assistance to the
committee, including an independent study of membership issues.
Expressions of interest are invited from individuals willing to serve
on this committee, which will address specific issues including but not
limited to:
a) membership structures and arrangements that will provide a world
wide representative body to nominate and elect the 9 At Large ICANN
board directors (with the goal of recommending three to five options to
the ICANN Board).
b) appropriate rights and obligations of members, including membership
application and registration requirements, membership fee structures,
liability limitation of members, and voting rights and procedures.
c) requirements and procedures for various forms of membership,
including individual, corporate and association.
d) efficient procedures for members to nominate and participate in the
election of At Large directors, and to participate in general meetings
of the corporation.
The work of the advisory committee will be open and inclusive of all
members of the Internet community. Draft and final recommendations
will be posted on the ICANN web site, and suggestions and comments via
the Internet will be invited from interested parties. Recommendations
from the committee will be subject to the notice and comment procedures
set forth in the Bylaws, Article III, Section 3.
The ICANN Board will select the committee with the goal of assembling a
diverse and broadly representative group. Expressions of interest to
participate are to be directed to msvh(a)icann.org, by midnight, 5
December, 1998, US west coast time. Applicants are requested to state
what contribution they would expect to make towards the work of this
committee; such statements need not be more than 100 words.
The committee will commence work in December, 1998. Most of the work
of the committee will be conducted via phone or the Internet. A final
meeting is planned to be held in Singapore on 1 March, 1999, to prepare
a report to the ICANN board by the end of March. Committee members will
be expected to devote sufficient time to the work of the committee to
achieve this very tight schedule.
Pending the identification of an ICANN funding mechanism and the actual
receipt of funds, ICANN's resources to support meeting and travel
expenses of its committees is very limited. We ask that committee
members assist us by assuming personal responsibility for their travel
expenses, if possible. We will facilitate phone participation in
face-to-face meetings as necessary.
Contact:
Molly Shaffer Van Houweling
Senior Advisor to the President and CEO
Staff to the Advisory Committee on Membership
ICANN
msvh(a)icann.org
____________________________________________________________________________
___
1998.11.24
Summary report of Monterey DNSO Meeting
---------------------------------------
The second DNSO formulation consultation meeting was held in Monterey,
Mexico
in 1998.11.15-17. This is the informal summary report of the meeting.
See www.dnso.org for the meeting minutes.
1. Around 40 people participated the meeting, similar to the first meeting
in
Bercelona in October 1998. Participation from Asia-Pacific was very
small.
Some trademark organizations such as INTA and CASIE participated, but not
ICC nor WIPO. gTLD registries such as NSI/InterNIC did not participate
this time either even though NSI participated the ad hoc meeting in
Boston
in the previous week.
2. We had (rough) consensus on structure, representation and funding this
time,
and decided to proceed to submit the application to ICANN by the end of
this year as recommendated by ICANN. Others may be applying, too.
3. DNSO structure and each constituency's representation to Names Council
are
as follows;
Names Council as the executive committee of DNSO
5 Constituencies 21
Registry 3+3
Registrar 3
Infrastructure and Connectivity Providers(ISP, Telco,..) 3
General Business(for- and non-profit) 3
Trademark 3
At Large(Other organizations and individuals) 3
Fair Hearing Panel(Option)
4. We set up the following teams to carry on the future work for DNSO
formulation.
Transition Team
Articulation, Liaison, Outreach
Drafting Team
Minutes and Application Document
We agreed to particularly emphasize on the outreach to include as many
stakeholders as possible to DNSO. [hope many AP* organizations to
participate in various constituencies of DNSO.]
Remark: The next ICANN Meetings will be held in March 1999 in Singapore
along
APRICOT, and 3 Supporting Organizations(Domain Name, Address, and
Protocol) are expected to be official approved then. The detail will
be announced shortly.(www.icann.org)
We need to agree with other major stakeholders such as NSI and ICC
prior to submission of the DNSO application to ICANN, or we will be
forced to coordinate after the application submission.
____________________________________________________________________________
___
---------
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
I have made some fairly rough and ready changes to my initial draft (now
over a month old) based on feedback received through this list.
This is still just "one possible solution". No flames please.
I have not been able to spend as much time as I would like polishing this
and thinking about the issues, since I've been working on this at nice -20
with frequent context switching :)
Consider this very drafty but a possible starting point for the meeting
tomorrow in Auckland.
Joe
---------
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
My racks don't have skins---no need since they are in a nice secure blockhouse---and I like the all-around access, but if I used racks I'd have to seismically brace the units (i.e. tie them to the shelves).
Besides, it offends me that they do quite a nifty job with the rack mount kits---one size fits all: front/centre/rear/wall mount @19" or 23"---and then I need a jemmy to install the box.
At least the PCMCIA slot on recent units is accessible (unlike on the 25xx series, oops).
---------
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog
Tena koe NZNOG,
My apology to tomorrow's meeting.
I am unable to be in Auckland at that time.
As I am unable to be there I do now want to contribute a note
on the matter of impacts created specifically for longer standing
ISPs where the routing of a single Class C subnet is altered
such that they have only ONE choice of NSP.
I do not believe that the meeting will be so foolhardy as to
agree to create a high level of disruption for my company and
others in similar situations as I anticipate that there is enough
awareness of the probable ramifications politically and legally.
It is obviously unwise to create a serious disruption or to
"be seen to limiting the basic commercial choice of an ISP to
purchase different upstream services".
However I think I should give you some detail of the type of impact there
would be at an older ISP (taken from what would happen at mine)
if NSP agreement is arrived at to act in this manner.
This is a helpful step towards giving the meeting full information.
Situation:
A well used Class C that is not part of larger block beholden to the ISP.
The Class C has been used rather fully for 5 years
Customer connections of the following kind operative under it:
Domestic and Business customers still operating statically configured
softwares from earlier days of setups. N.B. this significantly
predates the operations of entities like Xtra and Clearnet
and therefore there may be those connected to these operations who do
not have an appreciation of this dimension.
We are referring to
Older trumpet winsock,
older MacTCP,
Also however on the network concerned there are significant numbers of
customers operating
dialup masquerading/routing solutions that require a site visit and
some hours of work to alter,
dialup SMTPs that expect static allocation i.e.- to know their own
IP in advance of connecting.
So in the case of this operation if this class C is not independently routed
EITHER we cannot change NSP
OR I am talking about several hundred customers to appease if the routing is
withdrawn
...given that most customers will not quite understand a message telling them
to "reconfigure the IP settings of their software or fail to connect".
How do I deal with the consequent level of disruption compressed into a few hours?
One cannot.
If an ISP makes a monumental screw up such as in the Xtra password
debacle then they only have themselves to look to for how to cope with
the support impact. If however the cause is arguably from new policies
of NSPs imposed without agreement from the ISP and the result is scores of
businesses and many private users suddenly without connection -
.,. then this will be a very problematic situation even if both the ISP
and their customers had been given technical notice of a change.
So how can an ISP prepare when faced with the probability of this situation?
Obviously one can spend on and implement an IP translation setup for
all one's dialup traffic to be run through, or one can setup a separate dialup
zone and start to move customers who will not need the translation to dialling
that zone. Changing a phone number seems to be within customer reach
of comprehension and "self responsibility" given due notice. IP configurations
however are more often NOT viewed that way by the dialling public.. unfortunately.
The ISP end of the option to do translation for all or part of the
network is an elaborate commitment
and costly and doing it this way is not something that we would like to
see without seeing first that effort had been made practically, politically
and legally to avoid having to take such steps.
This is the extent of my thinking on emergency means to cope with a renumbering.
If someone out there has a technical solution I am not aware of then
please do share that here.
Most people who have actually heard us out on the sheer moment of
such changes in terms of hours and cost end up thinking more carefully
around the issues than before hearing such a description.
I strongly hope that this is true of the
majority attending tomorrow's meeting and advise the meeting that you should
be sure not to ignore the interests of long established ISPs. Their situation
is NOT to be compared with the impact of renumbering for some situation
like a law firm with 40 PCs. The additional impact for an ISP is that they
have multiple arrows of responsibility to customer situations where they
do not have much control. The business losses for an ISP can be quite
significant here and as for many of us the NSP supplier is also a competing ISP
os there would be quite a sting to the media tail that would emerge if
this matter is "forced" through mainly by the will of the NSP players.
In general I wish you a productive meeting where policies for
overall effectiveness of national route management are arrived at that set
new guidelines for new players.
Robert Hunt
---------
To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz
where the body of your message reads:
unsubscribe nznog