First draft of the European Template for IP number requests

  > Havard.Eidnes at runit.sintef.no writes:
  > 
  > +    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 yo
This is nice - you could be stronger and say there is general consensus on 
the need to reduce ....                                       ^^^^^^^^^
  > u
  > +    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"

I think it is still valid to mention this somewhere in the documentation.
(maybe in the more complete documentation that is planned)

  > 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 languag
  > e
  > > problem. Hosts are often thought of as > x m^3 big :-)
  > > An explanatory text should explicitly tell people to take also into accou
  > nt
  > > 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 (?).

or you could simply omit the word "host" and use "machine" as in something
like the following text:

         Please state the number of machines in your organisation that
         currently require a unique IP network number.  Do not forget to
         include terminal servers and transit networks when calculating
         this figure.

  > 
  > > 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?

I also think this is a good idea.  
  > 
  > > > 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.

I disagree - I have had many people answer with an "eh?" when I say "have
you got a service provider?"  The question is just intended as a double check
against those who have got service providers and yet think that they have to
go to the US for their network numbers ... it doesnt happen very often..but
it does happen. 
  > 
  > 
  > 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).

It's true that the information in Parts B, C and D is not needed for the 
RIPE database and therefore strictly there is no need to request the 
information in such a format from the user.  The rationale was, that
it would be easier to move the forms between NICs and to keep this very 
minimal form in English.  However if it is felt that the trade off for 
such a form is lots of confused users (= lots of queries to the NICs), 
then it obviously won't be worth it.  Might it be worth "piloting" various
types of forms??

 Regards,

     Anne.
  > 
  > 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