<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<TITLE>Message</TITLE>
<META content="MSHTML 5.50.4915.500" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=650223807-15052002>Amending RFC 2050 to reflect Enterprise LIRs is a good
idea, particularly as Telcos amongst others have valid reasons for
operating Enterprise LIRs. However, as previous manager of an Enterprise LIR
and my experience of dealing with large corporates as well as ISPs, I
see 2 problem areas;</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN
class=650223807-15052002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=650223807-15052002>1)
converting some organisations too become Enterprise LIRs is appropriate, but
they won't be interested in paying the LIR fees. They already have the
assignment, so why should they? :-)</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2></FONT> </DIV>
<DIV><SPAN class=650223807-15052002><FONT face=Arial color=#0000ff size=2>2)
RIPE (and ARIN & APNIC) database integrity. How accurate are the records of
the RIR databases? ISP LIRs are likely to be better than Enterprise
LIRs at maintaining their objects and contact information. Perhaps in the 2050
re-write some recommendations as to regular maintenance of objects to ensure
accurate, correct and current operational contacts, with yearly or 2 yearly
checks by the RIR, and recovery of address assignments from the Last Resort
after a period of time, such as 5 years, should be made.</FONT></SPAN></DIV>
<DIV><SPAN class=650223807-15052002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=650223807-15052002><FONT face=Arial color=#0000ff size=2>There
is also the problem that although Enterprise LIRs are mentioned in RIPE-185,
definition of them, their scope, and why they are different, isn't so well
documented :-)</FONT></SPAN></DIV>
<DIV><SPAN class=650223807-15052002><FONT face=Arial color=#0000ff
size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=650223807-15052002><FONT face=Arial color=#0000ff size=2>My
views do not necessarily reflect my employers :-)</FONT></SPAN></DIV>
<P><FONT face=Arial size=2>Regards,</FONT> </P>
<P><FONT face=Arial><FONT size=2>Adrian F Pauling<BR><SPAN
class=650223807-15052002></SPAN><FONT color=#0000ff>B<SPAN
class=650223807-15052002>T Ignite</SPAN></FONT></FONT></FONT><FONT
size=1><BR></P></FONT>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma
size=2>-----Original Message-----<BR><B>From:</B> Peter Emptage
[mailto:pemptage@cisco.com]<BR><B>Sent:</B> 14 May 2002 14:32<BR><B>To:</B>
lir-wg<BR><B>Subject:</B> IPv4 Address Allocation policies for organisations
not connecting to the Internet<BR><BR></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=312091613-14052002>There are a
limited number or organisations that for legitimate reasons require globally
unique address space apart from rfc1918 private address space, but
may not connect to or announce these prefixes on the Internet. Rfc 2050
referenced such situations as seen in the extract below.</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=312091613-14052002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=312091613-14052002>On a case by case
basis, it may be appropriate for these few organisations to become LIRs.
Perhaps the IPv4 Address Allocation policy should reference such circumstances
as rfc 2050 did?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=312091613-14052002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=312091613-14052002>Peter
Emptage</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=312091613-14052002>Senior Consulting
Engineer</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=312091613-14052002>Cisco
Systems</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=312091613-14052002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=312091613-14052002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=312091613-14052002>rfc 2050 extract
section 3a</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=312091613-14052002></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2>Assignment Framework</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> An assignment is the delegation of
authority over a block of IP<BR> addresses to an end
enterprise. The end enterprise will use<BR> addresses
from an assignment internally only; it will not sub-<BR> delegate
those addresses. This section discusses some of the
issues<BR> involved in assignments and the framework behind the
assignment of<BR> addresses.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2> In order for the Internet to scale
using existing technologies, use<BR> of regional registry services
should be limited to the assignment of<BR> IP addresses for
organizations meeting one or more of the following<BR>
conditions:</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial size=2><STRONG> a)
the organization has no intention of connecting
to<BR> the
Internet-either now or in the future-but it
still<BR> requires a
globally unique IP address. The
organization<BR> should
consider using reserved addresses from
RFC1918.<BR> If it is
determined this is not possible, they can
be<BR> issued unique (if
not Internet routable) IP
addresses.</STRONG></FONT></DIV></BLOCKQUOTE></BODY></HTML>