Subject: Second Call for Nominees

From: Danny McPherson <[email-masked]>
Date: Thu, 4 Nov 2004 08:26:47 -0700

Folks,
Please send your nominations for open IESG and IAB positions
to [email-masked], many thanks to those of you that have
already provided feedback to the NomCom.

IESG members whose terms are up are:

Harald Alvestrand -- IETF Chair
Bill Fenner -- Routing Area
Ted Hardie -- Applications Area
Russ Housley -- Security Area
David Kessens -- Operations & Management Area
Thomas Narten -- Internet Area
Jon Peterson -- Transport Area

IAB members whose terms are up are:

Bernard Aboba
Rob Austein
Sally Floyd
Jun-ichiro Itojun Hagino
Mark Handley
Geoff Huston

The nomination period will end Tuesday, November 23, 2004.

Any member of the IETF community may nominate any member of the
IETF community for any position.  Self-nominations are permitted and
encouraged.

Likewise, if you have any feedback regarding current incumbents, please
send it to [email-masked].

IAB desired qualifications can be found here:

http://www.iab.org/documents/docs/2004-10-21-iab-quals.html

IESG qualifications are included below.

Thanks!

-danny

[snip]
IESG Desired Qualifications

With the adoption of the new Nominations Committee procedures defined
in RFC 3777, the IESG is responsible for providing a summary of the
expertise desired of the candidates selected for open IESG positions.
This information is included below, and is suitable for publication to
the community, along with the Nomination Committee's request for
nominations.

We realize that this is a long list of demanding qualifications, and
that no one person will be able meet all of the requirements for a
specific position.  We trust that the NomCom will weigh all of these
qualifications and choose IESG members who represent the best possible
balance of these qualifications.

Generic Requirements:

IESG members are the managers of the IETF standards process. This
means that they must understand the way the IETF works, be good at
working with other people, be able to inspire and encourage other
people to work together on a volunteer basis, and have sound technical
judgment about IETF technology.

ADs select and directly manage the WG chairs, so IESG members should
possess sufficient interpersonal and management skills to manage
~15-30 part-time people.  Most ADs are also responsible for one or
more directorates or review teams.  So the ability to identify good
leaders and technical experts and recruit them for IETF work is
required. Having been a WG chair helps in understanding the WG chair
role, and will help in resolving problems and issues that a WG chair
may have.

In addition, all IESG members should have strong technical expertise
that crosses two or three IETF areas.  Ideally, an IESG member would
have made significant technical contributions in more than one IETF
area, preferably authoring documents and/or chairing WGs in more than
one area.

IESG members are expected to make sure that every document coming
before the IESG is properly reviewed.  Although IESG members may
delegate the actual review to individuals or review teams, the IESG
members will need to understand and represent the reviewers'
objections or comments. So the ability and willingness to read and
understand complex information quickly is another important attribute
in an IESG member.

It is helpful for an IESG member to have a good working knowledge of
the IETF document process and WG creation and chartering process.
This knowledge is most likely to be found in experienced IETF WG
chairs, but may also be found in authors of multiple documents.

IESG members must also have strong verbal and written communications
skills and a proven track record of leading and contributing to the
consensus of diverse groups.

A few comments on the IESG role:

Serving on the IESG requires a substantial time commitment.  The basic
IESG activities consume between 25 and 40 hours per week (varying by
area and by month, with the most time required immediately before IETF
meetings).  Most IESG members also participate in additional IETF
leadership activities, further increasing the time commitment for
those individuals.  It is also imperative that IESG members attend all
IETF meetings and up to two additional IESG retreats per year.
Because of the large time and travel commitments, employer support is
essential for an IESG member.

Applications Area:

The Applications Area focuses on applications that run across the
Internet and require some sort of standardized infrastructure to be
effective.  This includes, but is not limited to: E-Mail, instant
messaging systems, Web protocols, Directory services, printing
services and NetNews.

The Applications area often discusses whether something is properly
the realm of the IETF or "belongs" to other organizations.  Because of
this, and Applications AD needs to be willing and able to relate to a
wide range of non-IETF organizations.  An Applications AD also needs
to be someone that we can trust to make these critical decisions about
the scope of the IETF's work.

Because of the breadth of the Applications area, an Application AD
will have to deal with a large set of Internet applications protocols,
including many with which he or she may not have direct experience.
So, an Applications AD needs to be good at evaluating new approaches
to new problems and assessing the expertise of the people who bring
them to the IETF

Because the set of people in the Applications Area changes with the
protocols currently under development, the ability to clearly explain
how the IETF works, and to help new WGs work well within the IETF
framework is also important.

The Applications Area most often intersects with, and sometimes swaps
working groups or work items with, the Security Area (for
application-level security, or applications where security is an
important aspect) and the Transport Area (for issues with congestion
in applications, or interfacing with the multimedia and SIP WGs that
have traditionally been homed in Transport), so cross-area expertise
in either of these areas would be particularly useful.

Internet Area:

The primary technical areas covered by the Internet area include:
IP(v4 & v6), DNS, Host & Router Configuration, Mobility and Link-Layer
Security. The Internet Area is also responsible for defining how IP
will run over new link layer protocols as they are defined.

Internet ADs are expected to have a solid understanding of IPv4 and
IPv6, MTU and fragmentation related issues, various types of IP
addressing, IP forwarding and IP tunneling.

The Internet area has one of the broadest ranges of technical topics.
It has been typical of the Internet area to have its two Area
Directors divide the topics they specialize in, because it is too much
to expect that both ADs will have a very strong command of DNS,
Mobility, VPNs, IPv6, DHCP, Network Access Control and various
link-layer technologies.  The NomCom should consider the skills of the
sitting Internet Area Director and look for technical balance with
even more care than in other areas.

The Internet area intersects most frequently with the Routing Area
(particularly for IP Forwarding and Multicast), the Operations &
Management Area (for MIB development & Link-layer security mechanisms
(AAA/RADIUS)) and the Security Area (for IPsec and IKE).  So,
cross-area expertise in any of those areas would be particularly
useful.

Operations & Management Area:

The primary technical areas covered by the Operations & Management
area include: Network Management, AAA, DNS and various operational
issues facing the Internet (DNS operations, IPv6 operations, Routing
operations).

Unlike most IETF areas, the Operations & Management area is logically
divided into two separate functions: Network Management and
Operations.  David Kessens is responsible for the Operations portion
of the OPS area, so specific expertise required for the 2005 open
position would include a strong understanding of Internet operations
and a solid standing in the Internet operator community.

The Operations AD is largely responsible for soliciting operator
feedback and input regarding IETF work.  This is a challenging task
that requires strong contacts in the operations community and a great
deal of persistence.

Another important role of the Operations AD is to identify potential
or actual operational issues regarding IETF protocols and documents in
all areas, and to work with the other areas to resolve those issues.
This requires a strong understanding of how new and updated protocols
may affect operations, and the ability to gather information from the
operations community and translate that information into suggestions
for protocol architecture and design within the IETF.  It also
requires a strong cross-area understanding of IETF protocol
architecture and technologies.

The Operations portion of the OPS area intersects most often with the
Routing, Internet and Security areas.  So, cross-area expertise in any
of those areas would be particularly useful.

Routing Area:

The Routing Area is responsible for ensuring continuous operational
status of the Internet routing system by maintaining the scalability
and stability characteristics of the existing routing protocols, as
well as developing new protocols, extensions, and bug fixes in a
timely manner.

In particular, forwarding methods (such as destination-based unicast
and multicast forwarding, and MPLS), as well as associated routing and
signalling protocols (e.g., OSPF, IS-IS, BGP, RSVP-TE, PIM) are within
the scope of the Routing Area. The Area also works on Generalized MPLS
used in the control plane of optical networks and on security aspects
of the routing system.

A Routing AD is required to have solid knowledge of the Internet
routing system and its operations and must be proficient in at least
one of the mainstream routing protocols/technologies such as BGP,
OSPF, IS-IS, MPLS, GMPLS, or multicast. Implementation and deployment
experience, as well as significant contributions to the WGs in the
area are highly desirable.

The Routing area intersects most frequently with the Internet Area
(particularly for IP Forwarding and Multicast), the Operations &
Management Area (for MIB development) and the Security Area (for
Routing Protocol security). So, cross-area expertise in any of those
areas would be particularly useful.

Security Area:

The WGs within the Security Area are primarily focused on security
protocols.  They provide one or more of the security services:
integrity, authentication, non-repudiation, confidentiality, and
access control.  Since many of the security mechanisms needed to
provide these security services are cryptographic, key management is
also vital.

Security ADs are expected to ensure that all IETF specifications are
reviewed for adequate security coverage.  They also manage a set of
security resources that are available to most IETF areas and WGs.

Specific expertise required for a Security AD would include a strong
knowledge of IETF security protocols, particularly IPsec, IKE, and
TLS, and a good working knowledge of security protocols and mechanisms
that have been developed inside and outside the IETF, most notably
including PKI.

Also, a Security AD should understand how to weigh the security
requirements of a protocol against operational and implementation
requirements.  We must be pragmatic; otherwise people will not
implement and deploy the secure protocols that the IETF standardizes.

The Security Area intersects with all other IETF areas, and its ADs
are expected to read and understand the security implications of
documents in all areas.  So, broad knowledge of IETF technologies and
the ability to assimilate new information quickly are imperative for a
Security AD.

Transport Area:

The primary technical areas covered by the Transport area include:
Transport Protocols (TCP, UDP, SCTP), Congestion Control, NFS, IP
Telephony, SIP, and Signalling.

A Transport AD should have a good understanding of congestion control,
flow control, real-time transport protocols and other transport-level
issues that affect application layer protocols.  These basic transport
skills should also be augmented by strong interest and skills in
multimedia, VoIP, SIP, and such issues as NAT and identity.

The Transport area intersects most frequently with Internet Area, the
Applications Area and the Security Area.  So, cross-area expertise in
any of those areas would be particularly useful.

The Transport area is the largest IETF area, both in number of WGs to
manage (26) and in the number of documents in progress.  A Transport
AD must be prepared to invest more time than the average AD, just to
fulfill the basic requirements of the position.

IETF Chair:

The IETF Chair has four major roles: Representing the IETF to the
outside world, overseeing the work of the IETF as a whole, overseeing
the work of the IESG in particular, and serving as the General area
director.

Serving as IETF Chair is currently a full-time job. So, a candidate
for this position needs to be willing to put aside his or her own
technical work and other major professional roles for at least a
two-year period.

The IETF Chair is asked to speak at numerous conferences and to
represent the IETF to government officials, representatives of other
standards bodies and the press.  While the IETF Chair has control over
which of these invitations he or she accepts, any candidate for this
position should be willing and able to represent the IETF effectively
in these fora.

Chairing the IETF requires excellent communications skills, strong
leadership skills and the ability and willingness to keep the
community informed of all issues that are important to the IETF as a
whole, to establish community consensus on those issues and to speak
and act in accordance with that consensus.  Among other things, this
involves working with the IAB Chair to plan plenary sessions and
effectively running meetings with over 1000 attendees.

In the IESG chair role, the IETF chair is responsible for coordinating
the activities of the other twelve Area Directors and providing
top-level management for the IETF standards process. The IETF chair
must be capable of intervening when difficulties arise between ADs or
between an AD and a WG chair.  The IETF Chair also oversees the
handling of appeals sent to the IESG, the mechanisms for IESG internal
process change, and the production of any statements issued by the
IESG.

The IETF Chair also currently serves as the IETF's main contact point
with the IETF Secretariat, and works together with the IAB chair and
the ISOC President to manages the relationship with the RFC Editor.
It should be noted that this aspect of the IETF Chair role may change
significantly due to the Administrative Restructuring effort.

The General Area consists of a few IETF WGs and other activities
focused on supporting, updating and maintaining the IETF's standards
development process.  As General AD, the IETF chair should meet the
general requirements for an IESG member (listed above), and is
expected to play a full role in IESG document review and approval. The
General AD must also have a strong understanding of the IETF standards
process and a commitment to maintain and improve that process in a
careful and open manner.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 05 Nov 2004 10:19:48 +0100

Thomas' note reminded me that there are probably some people who haven't 
heard this yet....

I'm stepping down as IETF chair in March, and I am not a candidate for 
reappointment.

It's been a great four years, containing lots of learning experience, lots 
of hard work and lots of joy - but after four years as IETF chair, and ten 
years total on the IESG/IAB, March seems an appropriate time for me to 
leave this stage of my life behind.

The IETF is a great organization. I will enjoy watching it continue to grow 
and prosper under new leadership.

Thank you!

                  Harald

---

From: "Dr Harsh Verma" <[email-masked]>
Date: Fri, 5 Nov 2004 06:39:25 -0800

Kudos to you Harald!

Although I joined a bit late, it has been enjoying and very rewarding as a
learning experience watching the great effort by everyone and as you put it,
growth of the organization.

Thank you!

Harsh Verma
---------------------------------------------------------------------------
Dr Harsh Verma,
Director, R&D, Glocol Inc
Past Vice-Chair (Industry) R&D WG, NECCC
Ph: +1(916)684-3262  Mobile: +1(650)224-2108
E-Mail: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harald Tveit Alvestrand
Sent: Friday, November 05, 2004 1:20 AM
To: [email-masked]
Subject: Stepping down as IETF chair in March

Thank you!

                  Harald

---

From: Fred Baker <[email-masked]>
Date: Fri, 05 Nov 2004 07:58:32 -0800

>leave this stage of my life behind.

Thank you for the great deal of effort, and the success that you have 
achieved. I trust that your continuing career will still include IETF 
efforts and the betterment of the engineering of the Internet. I look 
forward to seeing what you will achieve.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 05 Nov 2004 18:17:59 +0100

--On fredag, november 05, 2004 07:58:32 -0800 Fred Baker <[email-masked]> 
wrote:

>> It's been a great four years, containing lots of learning experience,
>> lots  of hard work and lots of joy - but after four years as IETF chair,
>> and ten  years total on the IESG/IAB, March seems an appropriate time
>> for me to  leave this stage of my life behind.
>

Don't worry - I've long wanted to see what the peanut gallery looks like 
from the inside these days :-)

Expect to continue to see me around!

                     Harald

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 5 Nov 2004 12:38:21 -0800

Harald,

I would like to congratulate you on your successes, and suggest you have the
opportunity to be the last chair to preside over active work related to
version 4 of the IP protocol suite. With the publication of the tunneling
drafts that v6ops has been sitting on, there is no further need to discuss
32 bit address objects. At the same time, there is really no further
justification for any other IETF working group to be discussing 32 bit
addresses in current work. With all due respect to Geoff's efforts to
document the address growth rate in the routing system, even he acknowledges
that measure lags the allocation timeframe and assumes the RIRs will recover
all space currently considered lost. Given that IANA allocated 9 /8's over a
6 month period this year, coupled with the fact that only 78 /8's remain in
the useful part of the pool (ie: 52 month burn out), it should be clear to
everyone that products that rely on current standards activities will appear
in the market place after the central pool of 32 bit values has run dry. As
such I would recommend your legacy include an active review of all working
group discussions next week for items related to IPv4, followed by closure
of all 32 bit address related work items before your departure in March. 

Tony

---

From: [email-masked]
Date: Fri, 05 Nov 2004 16:31:46 -0500

On Fri, 05 Nov 2004 12:38:21 PST, Tony Hain said:

> the useful part of the pool (ie: 52 month burn out),

They said that just before CIDR happened, too.

>From the routing-table summary posted to the NANOG list this morning:

Number of addresses announced to Internet:                   1348239976
    Equivalent to 80 /8s, 92 /16s and 130 /24s
    Percentage of available address space announced:               36.4
    Percentage of allocated address space announced:               58.8
    Percentage of available address space allocated:               61.9

So 40% isn't even *allocated* yet (saying that we're probably burning /8's
faster than needed, but only 36% of the available space is actually routed.

Sounds to me like we've got more time than 52 months, if we start doing
stuff now to increase the usage efficiencies....
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: [email-masked]
Date: Fri, 05 Nov 2004 16:56:56 -0500

On Fri, 05 Nov 2004 22:48:16 +0100, Gert Doering said:
> Hi,
> 
> On Fri, Nov 05, 2004 at 04:31:46PM -0500, [email-masked] wrote:
> Do we really *want* that?
> 
> I'd rather go for "legacy-free networks".  Ditch v4, build proper v6
> networks.

Well.. that *would* be a preferable solution.  I was merely pointing out
that we're not quite as "up against the wall" as a projection of the burn
rate of /8's would indicate.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 05 Nov 2004 23:09:04 +0100

Of course not, please we don't want, neither need/should, do that !

If we decide to do that, let's say to the world "folks, IETF lost its
direction".

Regards,
Jordi

> De: Gert Doering <[email-masked]>
> Responder a: [email-masked]
> Fecha: Fri, 5 Nov 2004 22:48:16 +0100
> Para: [email-masked]
> CC: Tony Hain <[email-masked]>, 'Harald Tveit Alvestrand'
> <[email-masked]>, [email-masked], [email-masked], 'Pekka Savola'
> <[email-masked]>
> Asunto: Re: Stepping down as IETF chair in March - & - RE: A personal take on
> WG's priorities..
> 
> Hi,
> 
> Gert Doering
>       -- NetMaster
> -- 
> Total number of prefixes smaller than registry allocations:  66629  (65398)
> 
> SpaceNet AG                 Mail: [email-masked]
> Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
> 80807 Muenchen              Fax : +49-89-32356-299
> 
> 
> 

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Fred Baker <[email-masked]>
Date: Fri, 05 Nov 2004 14:05:28 -0800

Guys - please...

maybe it's just me, but it seems like this thread should be something about 
Harald. Coopting it to the continued wars between various competing 
technology religions seems just a tad disrespectful.

Could you at least change the subject line if we're going to go into this 
rathole again?

---

From: "Glen Zorn \(gwz\)" <[email-masked]>
Date: Fri, 5 Nov 2004 14:39:29 -0800

Fred Baker <> wrote:
> Guys - please...
> 
> maybe it's just me, but it seems like this thread should be
something
> about Harald. Coopting it to the continued wars between various
> competing technology religions seems just a tad disrespectful.  
> 
> Could you at least change the subject line if we're going to go
into
> this rathole again? 

Well said.

>>> So 40% isn't even *allocated* yet (saying that we're probably
>>> burning /8's faster than needed, but only 36% of the available
>>> space is actually routed. 
>>> 
>>> Sounds to me like we've got more time than 52 months, if we
start
>>> doing stuff now to increase the usage efficiencies....
>> 
>> Total number of prefixes smaller than registry allocations:
66629 
>> (65398) 

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by
simply
  listening to John Coltrane? -- Henry Gabriel

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 5 Nov 2004 16:42:04 -0800

> They said that just before CIDR happened, too.

and CIDR bought us time to get a replacement ready. 

> stuff now to increase the usage efficiencies....

Despite the desire to look for indicators that preclude having to learn
something new, it really doesn't matter how much of the space is routed.
What matters is the day someone new shows up to acquire space they intend to
route, only to find the reservoir dry. The number of routing entries is an
interesting operational measure, but what counts from a protocol viability
standpoint is the remaining useful space in the IANA pool.

We can always extend the lifetime of IPv4 by restricting the allocation
policies. The point is it is long past time to wake up and face the reality
that stricter conservation is directly contrary to expanding the reach and
capabilities of the global Internet. The IETF needs to be about developing a
growing and vibrant Internet, so resisting the inevitable change is counter
productive. In that light, it is time to remove the special status of
separate working groups for IPv6, and make it the default IP protocol for
all IETF work. 

Tony

---

From: Geoff Huston <[email-masked]>
Date: Sun, 07 Nov 2004 06:59:57 +1100

I would like to correct a few numbers in Tony's comments based on my work 
in this area that Tony has referred to.

The least squares best fit of advertised address space in the IPv4 domain 
over the past 5 years is a consumption rate of 4 /8s per year, slightly 
less than half of Tony's number

Even over the past 10 months the least squares best fit of data is a 
consumption rate of 5.5/8's per year

At this rate the central pool will exhaust in 2018, some 14 years hence. 
i.e. some 168 months hence. Allowing for an accelerating consumption rate 
at an exponential rate brings this forward to 10 years, or 120 months. 
(details of the analysis are at http://bgp.potaroo.net/ipv4/)

(Of course you should consult your favourite oracle, mystic, soothsayer or 
whatever for your own preferred version of the future.)

regards,

    Geoff

---

From: "Perry E. Metzger" <[email-masked]>
Date: Sat, 06 Nov 2004 21:31:37 -0500

> They said that just before CIDR happened, too.

We are already out of addresses. I cannot easily connect from my
laptop in my apartment (behind a NAT) with a friend's laptop in his
apartment (because it is also behind a NAT). This makes quickly
transferring pictures or documents from my machine to a friend's
machine a pain in the neck.

We ran out of addresses for practical purposes years ago. Anyone who
is running a NAT is doing so because it was easier to do that than to
try to get address space.

Perry

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sun, 07 Nov 2004 04:39:53 +0100

The need you describe is the true need of the users. What they discuss is 
IPv6 as an IPv4 patch better than NATs. You discuss tier to tier exchanges. 
This is almost a different vision of the network.

A vision IPv6 is properly design to support. The problem acknowledged by 
Michel Py and Steve Crocker, and others, mainly comes from the "a la IPv4" 
management of the IPv6 addressing plan. Innovation is blocked there. This 
is to do with ICANN's IANA and numbering plan organization and 
intergovernance, not with IPv6.

Please read Mr. Zhao's contribution drafts for ITU on the matter if you 
find one (I understand that he plans releasing his position by 
mid-November?). You document THE main need for IPv6: to permit a flexible 
management of tier and tier universal relations. For a while NAT helped a 
lot - and will continue and improve - at intranet level. But end-users need 
much more: a full control, that only IPv6 can deliver, as you show it. When 
an adequate IPv6 addressing plan is offered and used by end-users, NATs 
will disappear as useless, costly and obsolete constraints.

You cannot change things on the internet, you can only improve them and 
make them obsolete.
jfc

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 7 Nov 2004 12:36:53 -0800

> less than half of Tony's number

To continue the refinement; as you frequently point out as well, there is a
lag between request/assignment from the RIR and advertisement. Given that,
the advertisement growth you are quoting does not account for the recent
slope change in the IANA pool depletion I am referencing, and won't even
start to do so for another 6-12 months. 

> consumption rate of 5.5/8's per year

Let's be clear, consumption rate from the pool is not the same as
advertisement rate you are basing your measurements on. The size of the
advertised pool has absolutely no bearing on the size of the remaining stock
held by IANA or the RIR's. The slopes may be on a time delayed track, but
there is always the opportunity for addresses to be pulled from the pool yet
never advertised. As my I-D on 1918bis points out there are organizations
that have outgrown the available private space, so there only current option
is to acquire public space they never intend to route.

> At this rate the central pool will exhaust in 2018, some 14 years hence.

No, by your measure this is the date the advertised pool will be receiving
all possible prefixes. As we have discussed before, there are two problems
with these numbers, the first is that it assumes all currently reserved /8
prefixes can and will be used (by my count there were really only 78 useful
ones left in August), and second that it assumes that someone will find and
reclaim the ~13% of the space currently 'lost in the system' (the difference
between the IANA reserved and RIR-assigned).

> whatever for your own preferred version of the future.)

We can probably all agree that the 'last IPv4 address' will never be
acquired. Policies will become stricter until the price is so high that
nobody can afford it; or nobody will care once the replacement is deployed.

Tony 

> lots

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 7 Nov 2004 13:18:12 -0800

And for further clarification... I put this response together based on the
data I saw from Geoff a couple of months ago, and couldn't check the URL in
the air. Everyone should check the site because he has included further
evaluation of the data. I apologize for any perception or inference that
Geoff may not have been presenting valid data. The data he has been
presenting is valid for what it measures, our differences of opinion have
been over what and where to measure.

That said, I stand by the point that if the recent depletion rate of 9 /8s
in 6 months holds, there are only 58 months left. That event may have been
an anomaly, or it may be the precursor to an even more accelerated run rate.
We won't know for several years which it was.

Tony

> Tony Hain
> Sent: Sunday, November 07, 2004 12:37 PM
> To: 'Geoff Huston'; 'Harald Tveit Alvestrand'
> Cc: [email-masked]; [email-masked]; 'Pekka Savola'
> Subject: RE: IPv4 consumption statistics and extrapolations
> 
> Geoff Huston wrote:
> > >I would like to congratulate you on your successes, and suggest you
> have
> > the
> > >6 month period this year, coupled with the fact that only 78 /8's
> remain
> > in
> > >in the market place after the central pool of 32 bit values has run
dry.
> > As
> > > > of hard work and lots of joy - but after four years as IETF chair,
> and
> > ten
> > > > The IETF is a great organization. I will enjoy watching it continue
> to
> > > > grow

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Nov 2004 10:33:30 +0100

> We won't know for several years which it was.

Right. It's almost impossible to come up with good projections because 
there are many factors that are easily overlooked or too hard to 
quantify. A simple one is that /8s are reclaimed from time to time, 
which increases the number of available addresses and lowers the 
apparent burn rate. A much more complex issue is the practice of some 
ISPs to use old /8s they got way back when to give out addresses to 
their customers (4.0.0.0/8 is a good example). Once those private 
stashes are gone we'll see a higher burn rate. I think the fact that 
the whole broadband revolution doesn't show up in Geoff's statistics is 
a good indication that those statistics are incomplete.

What I'm afraid of is that we may end up in a situation where many 
people have all the addresses they need and don't see any reason to 
adopt IPv6, while others who are late to the table can't get sufficient 
IPv4 address space and will have to adopt IPv6 out of necessity, 
resulting in a fragmented internet where large groups can only 
communicate with each other using hideous NAT hacks.

>> Ietf mailing list

Would you guys please stop quoting previous messages verbatim? At this 
rate the SMTP protocol will break before the end of this debate.

---

From: Gert Doering <[email-masked]>
Date: Fri, 5 Nov 2004 22:48:16 +0100

Hi,

Gert Doering
        -- NetMaster

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 8 Nov 2004 14:09:37 -0500

> adopt IPv6, while others who are late to the table can't get 
> sufficient IPv4 address space and will have to adopt IPv6 out of 
> necessity, resulting in a fragmented internet where large groups can 
> only communicate with each other using hideous NAT hacks.

I can echo every part of this concern except for the use of future 
tense!

And, if people are already on opposite sides of NATs, it's easier for 
ideas like IPv9 to pop up ("the Great Firewall of China" discussion 
earlier this year, etc.)...

Spencer