First draft of the European Template for IP number requests

> > 	 Format: quantity of numbers requested followed by class of request.
> > 
> > 	 Example - req-typ:  1 class C
> > 
> > 	 In making the application, please be guided by the following 
> > 	 EXAMPLES of number of hosts which relate to the quantity of 
> >          network numbers requested:
> > 
> > 	  1 class C number (up to 255 hosts)
> > 	  2 class C numbers (up to 510 hosts) 	
> > 	  4 class C numbers (up to 1020 hosts)
> > 	  8 class C numbers (up to 2040 hosts)
> > 	 16 class C numbers (up to 4080 hosts)
> > 	 32 class C numbers (up to 8160 hosts)

I have for a while looked at these host numbers as somewhat inaccurate,
primarily since this does not take subnetting into account.  If you subnet
a class C network number (as some people end up doing, as was mentioned by
Peter Koch, since sometimes people have a small number of hosts at a given
site), you *always* waste address space, since subnet 0 and -1 and host 0
and -1 can (normally) not be used.  Thus, the best utilization one can make
of a subnetted class C network number is around 75% (if I haven't made an
error in my calculation).  If there is a need for two large subnets, the
largest potential utilization immediately drops to around 50%.

It is good to see that the number of subnets is asked for.

In connection with this, this is a part of a relatively recent addition to
the form I use:

+    Since there is a danger of IP addresses becoming a scarce resource,
+    there is a general desire to reduce the waste of IP addresses.
+    Therefore, please take the following points into consideration when you
+    evaluate your own need for IP addresses:
  
+     - A class C network may also be subnetted, and the subnet mask can at
+       least be chosen separately for each class C network.  You should
+       probably consider adopting the strategy for assignment of host and
+       subnet numbers outlined in RFC 1219.
  
+     - Newer routing protocols (OSPF) may support variable length subnet
+       masks. Likewise, if you use OSPF, you may tie together different
+       pieces of a subnetted network with (pieceds of) another IP network.
+ 

Ok, the reference to OSPF is probably too technical for this type of form
(and it is perhaps also a bit too advanced for most people), but you get
the direction I was thinking in.  Sometimes, people do not know (or "want"
to know) about subnetting C numbers, but I generally disregard arguments of
administrative ease and such... :-)

> > host-0:
> > 	 Please state the number of machines in your organisation that 
> > 	 currently require a unique IP network number (hosts).
> 
> The term 'host' often causes confusion here, which may be a local language
> problem. Hosts are often thought of as > x m^3 big :-)
> An explanatory text should explicitly tell people to take also into account
> PCs (terminal servers ...) and the like.

Yep. "Each and every box requiring a separate IP address is considered a
host in this terminology." is probably something in the direction of what
you want (?).

> Somewhere in the information package (here or in (c)) requestors should
> be guided to not forget transit networks when calculating their needs.
> And, in close relation with that, people should be asked to give an
> overview of the size of the different subnets, e.g. 17 subnets, 10 with <
> 20 hosts, the rest with up to 120 machines. This is often the case when
> large companies (e.g. insurance comp.) have some central administration
> and a number of regional offices.

I completely agree.  Should one mention unnumbered P-P serial links as a
possibility?  Or is this again too technical?

> > provider: 
> >          Please state whether you have an IP service provider.   
> >          An "IP service provider" is an organisation which can provide you
> >          with connectivity external to your network.

This seems to assume that the applicant already has established relations
with an IP service provider, which does not need to be the case.  However,
people most often know if they are going to connect to a service provider,
and who that would be.


Unfortunately, I have to agree with Duncan Rogerson that I also don't
really like the appearence of the new form too much.

The main objection I have goes in the same direction as Duncan's, I think,
as I see no reason to "formalize" the application form in the style of the
RIPE database entries, as long as this data isn't going to be stored in
such a system.  I also agree with Duncan that explanatory text should be
interspersed with the registration information (at least short versions of
it, as shown by Duncan).

My initial gut reaction was also that this form looked too complicated for
most people to grasp and understand easily, and that this thus may cause
more load on us, the delegated registries, explaining what needs to be
filled in and what can be left out in each case.  In my form I have a
"nic-hdl" entry for the persons in addition to address, phone etc., and
even though I have stated

    The nic-hdl is optional, as explained in the attached document (ripe-50).

I still get questions about it (ok, not many, but you probably see my
point...)


- Havard