policy change: static verification methods

Hi Paula et al.

I, and as far as I know, a couple of other LIR:s, have no objections for the
proposed policy, on the contrary. The proposal has a pretty fine tune in
balancing the end-customer need as stated as one of our assigning goals in
RIPE-185, and the not-that-good policy comment of CATV-network customers as
beeing as any dial-up customers, just becouse they are using a modem. As far
as I recon, one have to use a 'modem' when going for a Leased Line as well,
though signalling would not be analog.

Any way, I think it perfectly ok to implement the policy right away.

Best regards
Per Lundberg/Sonera Registry/RSS11-RIPE

> -----Original Message-----
> From: Paula Caslav [mailto:paula at ripe.net]
> Sent: Tuesday, February 23, 1999 4:44 PM
> To: lir-wg at ripe.net
> Cc: local-ir at ripe.net
> Subject: policy change: static verification methods
> 
> 
> 
> Hello all,
> 
> A few weeks ago I send the following proposal to the lir-wg mailing 
> list for comments. Since no comments were received, we are assuming 
> that nobody has objections to change the policy. We have therefore 
> decided to implement it starting immediately.
> 
> Kind regards,
> 
> Paula Caslav
> RIPE NCC
> 
> ------- Forwarded Message
> 
> Date:     Wed, 10 Feb 1999 14:38:52 +0100
> From:     Paula Caslav <paula at ripe.net>
> Sender:   owner-lir-wg at ripe.net
> To:       lir-wg at ripe.net
> Subject:  static verification methods
> 
> 
> Hello all,
> 
> At the Local IR working group at RIPE 32, the issue was raised about
> changing the policy for applying verification methods to cable
> connections. Here is our proposal on how to change this policy.
> 
> First some background: A few years ago, the IANA asked the Regional
> Registries to keep an eye on "very small assignments to
> individuals". This means cases like static dial-up where a registry
> has to use one IP address per dial-up customer. Since these kinds of
> assignments could potentially use up a lot of address space, it was
> decided to strongly discourage using static addresses for this and
> that that we should monitor these assignments more closely. To do
> this, any Local Registry that assigns a lot of addresses for this
> purpose (more than 1024 addresses), was requested that they would have
> to enter each of these customers in the database individually (as is
> the case with all assignments to end-users). Later when some Local
> Registries had a problem with entering all their dial-up customers in
> the database for confidentiality problems, it was decided to add an
> alternative method that they could instead send us a weekly report
> showing the customers they added that week. This is so that the
> Regional Registries could still keep track of these kinds of
> assignments.
> 
> In the last few years, more and more technologies have come along that
> fall under this procedure. Aside from static dial-up, other services
> such as web hosting (when not using http 1.1), cable connections, ADSL
> connections, some ISDN connections, etc.. often need to assign one IP
> address per customer. In many of these cases, using one IP address per
> customer is necessary because the host is usually permanently
> connected to the Internet.
> 
> The issue was raised that applying these verification methods to
> technologies that are permanently connected to the Internet and need
> one IP address per customer, is too cumbersome and adds a lot of extra
> administrative overhead for the provider. We also realise that there 
> are inconsistencies between the Regional Registries in dealing with 
> these technologies.
> 
> For these reasons, we would like to change the policy and make a 
> distinction between technologies that are usually connected to the 
> Internet permanently
> and those that are connected only temporarily. Here is the 
> proposal for 
> the new policy, please give us your comments by the end of next week.
> 
> Permanently online:
> 
> This includes technologies such as cable, ADSL, and various server
> (web, ftp, etc..) connections that are usually permanently
> connected to the Internet. It can also include analogue or digital
> (ISDN) dial-up connections if they are used for a service that needs
> to be permanently online and for services like dial-out on demand.
> 
> For most of these connections, you need to assign one IP address per
> connection, even if using DHCP (which we recommend because it makes
> renumbering easier). We propose to change the policy and to not apply
> the verification methods to these types of connections.
> 
> For these technologies, we still need to keep track of the amounts of
> addresses being assigned, however we would do this whenever the
> customer requests a new assignment for this purpose. Since these
> services are permanently connected to the Internet, we will probe
> these addresses to verify whether the assigned addresses really are in
> use. It must therefore be made clear to the RIPE NCC exactly which
> block of IP addresses is used for this purpose. We would expect to see
> that a high percentage are reachable. We might at this point request
> additional information to show that they have really used the
> addresses that were assigned for this purpose in the past- this could
> be in the form of a list of all URLs assigned, their DNS records,
> config files, etc.. something to show that the IP addresses are all in
> use.
> 
> Virtual web hosting is the only one that has an alternative available
> (http 1.1) that would allow assigning one IP address for several
> hosts. Since we want to encourage that people use http 1.1, we propose
> to continue applying the special verification methods to virtual web
> hosting that doesn't use http 1.1.
> 
> Temporarily online:
> 
> This includes technologies that only need to be connected to the
> Internet temporarily, such as most telephone dial-up connections. We
> recommend the use of DHCP and assigning IP addresses based on the
> number of modem ports. We will therefore continue to apply the special
> verification methods to any organisation that assigns IP addresses
> based on the number of customers instead.
> 
> 
> 
> 
> 
> 
> 
> ------- End of Forwarded Message
> 
> 
>