From Anne.Lord at ripe.net Thu Dec 3 14:58:21 1992 From: Anne.Lord at ripe.net (Anne Lord) Date: Thu, 03 Dec 92 14:58:21 +0100 Subject: First draft of the European Template for IP number requests Message-ID: <9212031358.AA11296@ncc.ripe.net> Dear All, Below are two documents which comprise the RIPE NCC's first draft of the European IP network number request form. The first comprises the bare bones of the template, which will be completed and returned to the local registry. The second document gives guidelines on how to correctly complete the template. The idea is that it is this second document which can be translated for local use, but that the basic template is to remain in English, in case the it needs to be forwarded to another country. In drafting the document, sections from both the the templates of JANET NIC and the Norwegian NIC were incorporated. Comments on this draft are welcome and appreciated. Please send your comments to the list (or to me if they are minor comments). Many thanks, Anne. -----------------------cut here-------------------------------- DRAFT December 1992 RIPE NCC EUROPEAN IP NUMBER REQUEST FORM ------------------------------- It is *essential* that you read the supporting documentation before completing the form below. There are 3 documents which you should receive and read: a) the IP number request form - this document b) guidelines on how to complete the IP number request form c) what you should know before applying for IP network numbers (draft is being prepared by Bob Day) This form is the basic template which you should complete and return to us. The more complete the information you supply to us now, the quicker we will process your request. Further related documentation is available from: rfc's etc. PLEASE RETURN THIS DOCUMENT TO: local ir-registry name
Part A ------ The information supplied for this section together with the assigned network numbers will be entered into a database of European network numbers and their contact information which is accessible by the whole Internet community. netname: descr: descr: country: admin-c: tech-c: changed: source: RIPE person: address: address: address: address: phone: fax-no: e-mail: changed: source: RIPE person: address: address: address: address: phone: fax-no: e-mail: changed: source: RIPE Part B ------ Information supplied below helps us to evaluate and process your request. It will be kept in strict CONFIDENCE and NOT entered into the RIPE Network Management Database. req-typ: provider: inet-con: cust-ip host-0: host-1: host-2: sub-0: sub-1: sub-2: ip-prov: use-net: iso-net: Part C ------ Complete the section below *ONLY IF* you are making an application on behalf of another organisation. app-by: org-by: add-by: ph-by: fax-by: app-for: org-for: add-for: ph-for: fax-for: Part D ------ If you are applying for more than 2 Class C network numbers then on a separate page, please submit a description of your network plans. The more numbers you are requesting, the more detailed your technical description will need to be. Furthermore, the more detail you provide, the quicker we will be able to process your application. Please ensure that you have read all the supporting documentation before completing this section (currently under preparation). This is important whatever class of network number you are applying for, but especially important if you are applying for a class B, as it contains a number of helpful hints. Furthermore if you are applying for a class B, your application may be referred to the RIPE Network Coordination Centre in Amsterdam for adjudication. Current network layout: Future network plans: --------------------------------cut here------------------------ DRAFT December 1992 RIPE NCC GUIDELINES ON HOW TO COMPLETE THE IP NUMBER REQUEST FORM -------------------------------------------------------- It is *essential* that you read ALL supporting documentation before applying for your network numbers. There are 3 documents which you should receive and read: a) the IP number request form b) guidelines on how to complete the IP number request form - this document c) what you should know before applying for IP network numbers (draft is being prepared by Bob Day) This document will guide you in how to complete the IP number request form correctly. The more complete the information you supply to us now, the quicker we will be able to process your application. Further related documentation is available from: rfc's etc PLEASE RETURN THIS DOCUMENT TO: local ir-registry name
Part A: ------ The information supplied for this section together with the assigned network numbers will be entered into a database of European network numbers and their contact information which is accessible by the whole Internet community. netname: Please complete with an appropriate network name for the network to be numbered which is short and meaningful. This name is not related to any host name. It is used mainly for administrative purposes like consistency checking of the Internet Registry. You will very likely not see this name appear anywhere, but on forms like this. Format: Please complete only with capital letters. Network names should NOT start with anything other than a capital letter. Dashes can be used as shown below. A "-NET" suffix is quite a common naming format. example - netname: TBIT-NET descr: Please complete with a short description of the organisation, including the location. The full postal address is not needed as this is required and will be specified in the person template. Format: free text, one line per entry, multiple lines in sequence. example - descr: Terabit Labs Inc. descr: Network Bugs Feeding Facility descr: Northtown country: Please give the ISO 3166 two letter country code which is appropriate for the organisation. We know this gives problems for networks crossing national boundaries, so choose the most appropriate country, based on the location of the admin contact. If you do not know the ISO code for your country, please complete with the full name of the country. Format: ISO 3166 two letter country code in CAPITAL LETTERS Example - country: IE admin-c: Please complete with the name or NIC handle of the person who is the administrative contact for the network. The NIC handle (if known) is preferred. Format: or the NIC handle if known. Example - admin-c: John E Doe tech-c: Please give the name of technical contact person. There can be multiple technical contacts names. NOTE: both the admin-c: and tech-c: fields MUST be completed. If two different names for each function are not applicable, then please use the same name for both contacts. Format: as in admin-c. changed: Email address of the person who is completing the template, followed by the current date. If you do not have email connectivity please leave blank and we will complete it. Format: YYMMDD. Example - changed: johndoe at terabit-labs.nn 900401 source: Source of the information. This will always be RIPE. Example - source: RIPE PERSON TEMPLATE NOTES Please ensure that you complete as many person templates as there are different persons specified in the network template unless the data about those persons is already in the RIPE database. person: Please give the full name of either the admin-c contact or the tech-c contact. There must be a person template completed for each person. The names must be identical to those given above in the "admin-c:" and "tech-c:" attributes (but must not be the NIC handle). Format: Example - person: John E Doe address: Please complete with the full postal address. Include everything necessary for paper mail to be delivered. Format: multiple lines of text. City and post code on a single line. Country on the last line. Example - address: Terabit Labs Inc. address: Industrial Estate North address: North Perpendicular Road 12 address: NN-1234 Northtown address: Repubic of Northern Nowhere phone: Please give the work telephone number of the person (or NIC handle) specified above. Multiple telephone numbers are acceptable. Each telephone number should be put on a separate line, one line per number in order of the most appropriate number for the contact person first. Format: International + . If no direct inward dialling is available, please append "ext." and extension number. Example - phone: +31 20 12334676 phone: +44 123 987654 ext. 4711 fax-no: Please complete with the telefax number of the person (or NIC handle) specified above. Format: the same as for the telephone number above. Example - fax-no: +31 20 12334677 e-mail: Please supply the appropriate electronic mail address for the contact. If you DO NOT have e-mail connectivity, please insert . Format: Valid domain address please. (If possible please do not include the following characters in the address !, %, ::). Example - e-mail: johndoe at terabit-labs.nn or e-mail: nic-hdl: This refers to a NIC handle which is a unique identifier assigned and used by the US NIC to unambiguously refer to Internet people. If you do not have a NIC handle, then please leave blank. Format: NIC format. Example - nic-hdl: JD0401 changed: Who and when changed this last. Please complete with your e-mail address followed by the current date in the format specified below. If you do not have e-mail connectivity, please leave blank and we will complete this on your behalf. Format: YYMMDD: Example - changed: johndoe at terabit-labs.nn 920913 source: Source of the information. This should always be RIPE. Example - source: RIPE PART B ------ Information supplied below helps us to evaluate and process your request. It will be kept in strict CONFIDENCE and NOT entered into the RIPE Network Management Database. req-typ: This refers to the "request type". Please specify the quantity and class of your request for network numbers. 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) a single class B number (class B requests may be referred to the RIPE NCC for adjudication) other (please specify) 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. Format: please answer with the name of your provider or if you do not have an IP service provider answer with a "no". Example: - provider: Connections Company, Northern Nowhere inet-con: Please state whether you plan to connect to the Internet. Format: please answer with whichever of the following options most closely describes the position of your organisation. - will never connect - already connected - plan to connect If you are "already connected" to the Internet, please state through whom you are connected and to which network. If you answer with "plan to connect" then please make an estimation on the date that you hope to connect, specifying the month and the year (if possible). Example - inet-con: already connected JANET in the UK or Example - inet-con: plan to connect December 1993 host-0: Please state the number of machines in your organisation that currently require a unique IP network number (hosts). Format: complete with a number. Example - host-0: 100 host-1: Estimate the number of machines requiring a unique IP network number (hosts) in one years time. Format: as above. Example - host-1: 134 host-2: Estimate the number of machines requiring a unique IP network number (hosts) in two years time. Format: as above. Example - Host-2: 250 sub-0: Please state the number of subnets required for the current network. A subnet refers to the physical parts of the network which need a unique (sub)net number. Format: complete with a number. Example - sub-0: 10 sub-1: Estimate the number of subnets in one years time. Format: as above. sub-2: Estimate the number of subnets in two years time. Format: as above. ip-prov: Please answer the question - Does your organisation provide IP services to other organisations? Format: complete with Yes or No. Example - ip-prov: No or Example - ip-prov: Yes use-net: Please answer the question - has your organisation already obtained an IP network number or numbers? If so, please give the network number(s). If not, then please complete with . Format: complete with the network number only - four numbers separated by dots, as shown below. Example - use-net: 193.87.45.0 or Example - use-net: iso-net: Please give the ISO 3166 country code which describes where the network will be located. If more than one country applies, then give the name of the country "responsible" for the network, using the country of the admin-c: contact given in Part A. Format: complete with country name using ISO 3166 country code. Example - iso-net: NL Part C: ------ Complete this section *ONLY IF* you are completing this template on behalf of another organisation. If you are not, please leave this section blank because contact and organisational details have been given in Part A. app-by: Who is this application being made by? Please give a contact name. Format: Example - app-by: Joe Bloggs org-by: Format: name of your organisation. Example - org-by: Bloggs Software Consultancy add-by: Address of the organisation responsible for this request. Format should follow the example in the "address" object in Part A. ph-by: Telephone number for the above organisation. Format should follow the example given for the "phone" object in part A. fax-by: Fax number for the above organisation. Format should follow the example given in the "fax" object in Part A. app-for: Who is this application being made for? Format: . Example - app-by: Mrs E Smith org-for: Name of organsation FOR whom the application is being made. Format and example should follow the example in the "org-by" object given above. add-for: Address of organisation FOR whom the application is being made. Format should follow the example given for the "address" object in Part A. ph-for: Telephone number of organisation in "add-for" object above. Format should follow the example given for the "phone" object in Part A. fax-for: Fax number of organisation in "add-for" object above. Format should follow the example given for the "fax" object in Part A. Part D: ------ If you are applying for more than 2 Class C network numbers then on a separate page, please submit a description of your network plans. The more numbers you are requesting, the more detailed your technical description will need to be. Furthermore, the more detail you provide, the quicker we will be able to process your application. Please read the supporting documentation (currently under preparation) which will guide you. It is particularly important to read this document if you are applying for a class B network number, as it provides a number of helpful hints. It is available from: Please consider the following in your description: Current network layout: Future network plans: From D.Rogerson at nosc.ja.net Thu Dec 3 17:13:22 1992 From: D.Rogerson at nosc.ja.net (Duncan Rogerson) Date: Thu, 3 Dec 1992 16:13:22 +0000 (GMT) Subject: First draft of the European Template for IP number requests Message-ID: <9212031613.AA18566@tarquin.ja.net> My first reaction is that I don't really like this too much I'm afraid. I think splitting the field and the explanation for a field is a bad idea. I know the idea was to have a pan-European form, and then have the information required to fill it in in the local language as a separate part, but looking at it, I think this is just going to be confusing to people and generate more work dealing with enquiries over the phone. I think it's better to merge the information about each field with the question itself. The information can still be translated to the local language, and we can still make available the more verbose documentation. For example : Part A The information supplied for this section ... etc etc 1. Please give the suggested name of the network, a short description of the organisation and location, the ISO 3166 code for the country in which the network is located, the administrative and technical contact names for the network, and the author and date of completion of the template. netname: descr: . . source: RIPE This would also mean we could send out less paperwork (save the trees! save the fax machines!) initially. We can add a sentence at the top of the form asking that if the recipient needs more information on completing the form, documents x y and z are available from the local registry. We can then send them the more detailed information about each field. Part C is a nice feature, we've had quite a few applications on behalf of other organisations. It might be nice to have a question asking where notification of the allocation should go - to the end organisation or the intermediary, this seems to vary for some reason. Part D is good - is it worth stating on the form that class B addresses are only allocated in very exceptional circumstances ? I've started adding this to forms I send out direct, and I think it's helping to make peoplet think more carefully about their networks. Dunc From pmk at deins.informatik.uni-dortmund.de Fri Dec 4 11:17:38 1992 From: pmk at deins.informatik.uni-dortmund.de (Peter Koch) Date: Fri, 04 Dec 92 11:17:38 N Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Thu, 03 Dec 92 14:58:21 +0100. <9212031358.AA11296@ncc.ripe.net> Message-ID: <9212041018.AA17724@meins.informatik.uni-dortmund.de> Anne, > Comments on this draft are welcome and appreciated. Please send your > comments to the list (or to me if they are minor comments). > > DRAFT December 1992 > RIPE NCC > > GUIDELINES ON HOW TO COMPLETE THE IP NUMBER REQUEST FORM > -------------------------------------------------------- [...] > Part A: > ------ > > The information supplied for this section together with the assigned network > numbers will be entered into a database of European network numbers and their > contact information which is accessible by the whole Internet community. > > netname: > Please complete with an appropriate network name for the network > to be numbered which is short and meaningful. This name is not > related to any host name. It is used mainly for administrative > purposes like consistency checking of the Internet Registry. You > will very likely not see this name appear anywhere, but on forms > like this. One problem that often arises is confusion with the DNS. A sentence explaining that both naming schemes have absolutely nothing in common should be added. Just telling them about hostnames is not enough (tm) . > Format: Please complete only with capital letters. Network names > should NOT start with anything other than a capital letter. Dashes > can be used as shown below. A "-NET" suffix is quite a common naming > format. ... and is totally redundant. In fact, we would discourage people to have some kind of 'LAN' or 'NET' in their network names. This is mainly because - as to my knowledge - there is a restriction on the length of these names which allows them to be only up to 12 characters long. If we no longer have to cope with this - as I don't see it mentioned here - some sort of suffix may be ok. > example - netname: TBIT-NET > > descr: [...] > country: > Please give the ISO 3166 two letter country code which is appropriate > for the organisation. We know this gives problems for networks > crossing national boundaries, so choose the most appropriate country, > based on the location of the admin contact. If you do not know the > ISO code for your country, please complete with the full name of the > country. The local IR could mention the local ISO3166 code here, or we could attach a list of all (European) codes to the explanatory section. > Format: ISO 3166 two letter country code in CAPITAL LETTERS > > Example - country: IE > > admin-c: > Please complete with the name or NIC handle of the person who is > the administrative contact for the network. The NIC handle (if > known) is preferred. > > Format: or the NIC handle if > known. > > Example - admin-c: John E Doe This is a very detail and may better be discussed elsewhere, but if you prefer "John E Doe" to "John E. Doe", this should more clearly be pointed out. The requestor should be guided to leave out titles like 'Dr.' here, too. > tech-c: [...] > PERSON TEMPLATE NOTES > > Please ensure that you complete as many person templates as there are > different persons specified in the network template unless the data > about those persons is already in the RIPE database. [...] > address: > Please complete with the full postal address. Include everything > necessary for paper mail to be delivered. > > Format: multiple lines of text. City and post code on a single > line. Country on the last line. > > Example - address: Terabit Labs Inc. > address: Industrial Estate North > address: North Perpendicular Road 12 > address: NN-1234 Northtown > address: Repubic of Northern Nowhere This may also be more appropriate on the db-wg list, but I remember some rumors, that the 'country' attribute would be added to the person object ... > phone: [...] > PART B > ------ > > Information supplied below helps us to evaluate and process your request. > It will be kept in strict CONFIDENCE and NOT entered into the RIPE Network > Management Database. > > req-typ: > This refers to the "request type". Please specify the quantity and > class of your request for network numbers. > > 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) The numbers should read 254 * n and the info-sheet should explain why. Nice to see this 32-C-block here ... > a single class B number (class B requests may be referred to the > RIPE NCC for adjudication) > other (please specify) This could make requestors switch over to contacting RIPE NCC direct for class B requests. I think we do not want this happen, so better say it unambigously. > provider: [...] > 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. > Format: complete with a number. > > Example - host-0: 100 > > host-1: [...] > sub-0: > Please state the number of subnets required for the current network. > A subnet refers to the physical parts of the network which need a > unique (sub)net number. It is a very good idea to ask for this information, as it is really missing to date and we have to call the requestor for it every now and then. It could also prevent people from just copying the host numbers from the req-typ field into the host-? fields, which may happen if the host number seems to be the only figure of interest. ["How many hosts do I need to have for receiving a class B address?"] > Format: complete with a number. > > Example - sub-0: 10 > > sub-1: > Estimate the number of subnets in one years time. > > Format: as above. > > sub-2: > Estimate the number of subnets in two years time. > > Format: as above. 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. > ip-prov: [...] > use-net: > Please answer the question - has your organisation already obtained > an IP network number or numbers? If so, please give the network > number(s). If not, then please complete with . > > Format: complete with the network number only - four numbers > separated by dots, as shown below. > > Example - use-net: 193.87.45.0 > or > Example - use-net: For easier error detection/consistency checking the network name could additionally be mentioned, if possible, i.e. if known. > iso-net: [...] > Part D: > ------ > > If you are applying for more than 2 Class C network numbers then > on a separate page, please submit a description of your network plans. > The more numbers you are requesting, the more detailed your technical > description will need to be. Furthermore, the more detail you provide, > the quicker we will be able to process your application. > > Please read the supporting documentation (currently under preparation) > which will guide you. It is particularly important to read this document > if you are applying for a class B network number, as it provides a number > of helpful hints. It is available from: > > Please consider the following in your description: It is always a good idea to ask requestors for B addresses what subnet mask they want to apply. > Current network layout: > Future network plans: just my 2 cents ... regards, Peter From Anne.Lord at ripe.net Wed Dec 9 10:44:35 1992 From: Anne.Lord at ripe.net (Anne Lord) Date: Wed, 09 Dec 92 10:44:35 +0100 Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Thu, 03 Dec 92 16:13:22 GMT. <9212031613.AA18566@tarquin.ja.net> Message-ID: <9212090944.AA18410@ncc.ripe.net> > Duncan Rogerson writes: > My first reaction is that I don't really like this too much > I'm afraid. > > I think splitting the field and the explanation for a field is a > bad idea. I know the idea was to have a pan-European form, and > then have the information required to fill it in in the local > language as a separate part, but looking at it, I think this > is just going to be confusing to people and generate more work > dealing with enquiries over the phone. > Duncan, Many thanks for your prompt reaction to the draft template. I do think however that this format still has validity. These are my reasons why: a) Sometimes the IP applications are passed between NICs in different countries as it is not always entirely clear who should handle the application - therefore the argument for keeping a separate and uncluttered looking form - in English (increasing its transparency) - is quite a strong one. The local language version is something to be composed by the local NICs which explains how to fill in the form. This was agreed at the ir-registry BOF in Paris wasnt it? b) Also the idea behind this bare bones template + explanations on how to fill in the template is to avoid users thinking they know how to fill in the form without looking at *any* additional documentation (which will of course take up more of their time and might be considered a drag..) This form is actually designed so as to be difficult to fill in *without* reading the documentation - quite carefully - first. > I think it's better to merge the information about each field > with the question itself. The information can still be > translated to the local language, and we can still make > available the more verbose documentation. For example : > > Part A > > The information supplied for this section ... etc etc > > 1. Please give the suggested name of the network, a short description > of the organisation and location, the ISO 3166 code for the country > in which the network is located, the administrative and technical > contact names for the network, and the author and date of > completion of the template. > > netname: > descr: > . > . > source: RIPE > This I think is confusing (ok so it's only a matter of personal taste) BUT I do think you run the risk of getting information back to you in a format that will require quite a bit of massaging.. and is possibly incomplete. > This would also mean we could send out less paperwork (save the trees! > save the fax machines!) initially. We can add a sentence at the top You have a point about the amount of paper used - I will look at deleting some of the blank lines.. > of the form asking that if the recipient needs more information on > completing the form, documents x y and z are available from the > local registry. We can then send them the more detailed information > about each field. I think you also run the risk of receiving many more telephone calls as people have odd one off queries. The supporting documentation attempts to stem these queries from the start and aims at getting quality information. Also I believe that people are quite lazy, often in a rush etc. and you will get people trying to fill in the form without getting the additional documentation or bothering to make that extra telephone call. Actually this is probably more likely than receiving hundreds of phone calls. The template is built around the idea of the RIPE database wich includes explanations on how to fill in each field and this seems to be understood ok. I have also tried this form out on a couple of "users" (ok not a huge sample size :-) ) they made some useful comments but found it ok to use. > > Part C is a nice feature, we've had quite a few applications on > behalf of other organisations. It might be nice to have a question > asking where notification of the allocation should go - to the > end organisation or the intermediary, this seems to vary for some > reason. > > Part D is good - is it worth stating on the form that class B > addresses are only allocated in very exceptional circumstances ? > I've started adding this to forms I send out direct, and I think > it's helping to make peoplet think more carefully about their > networks. > > Dunc This is a good idea. The supporting documentation (under draft by Bob Day) ought also to include information about the (lack of) address space etc..etc.. Regards, Anne. From Anne.Lord at ripe.net Wed Dec 9 13:11:36 1992 From: Anne.Lord at ripe.net (Anne Lord) Date: Wed, 09 Dec 92 13:11:36 +0100 Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Fri, 04 Dec 92 11:17:38 +0100. <9212041018.AA17724@meins.informatik.uni-dortmund.de> Message-ID: <9212091211.AA18516@ncc.ripe.net> > "Peter Koch" writes: > > > > The information supplied for this section together with the assigned netw > ork > > numbers will be entered into a database of European network numbers and t > heir > > contact information which is accessible by the whole Internet community. > > > > netname: > > Please complete with an appropriate network name for the network > > to be numbered which is short and meaningful. This name is not > > related to any host name. It is used mainly for administrative > > purposes like consistency checking of the Internet Registry. You > > will very likely not see this name appear anywhere, but on forms > > like this. > > One problem that often arises is confusion with the DNS. A sentence explain > ing > that both naming schemes have absolutely nothing in common should be added. > Just telling them about hostnames is not enough (tm) . > Good point. Done. > > Format: Please complete only with capital letters. Network name > s > > should NOT start with anything other than a capital letter. Dashes > > can be used as shown below. A "-NET" suffix is quite a common naming > > format. > > ... and is totally redundant. In fact, we would discourage people to have s > ome > kind of 'LAN' or 'NET' in their network names. This is mainly because - as > to my knowledge - there is a restriction on the length of these names which > allows them to be only up to 12 characters long. If we no longer have to co > pe > with this - as I don't see it mentioned here - some sort of suffix may be o > k. > > > example - netname: TBIT-NET Ditto. > > > > descr: > [...] > > > country: > > Please give the ISO 3166 two letter country code which is appropriate > > for the organisation. We know this gives problems for networks > > crossing national boundaries, so choose the most appropriate country, > > based on the location of the admin contact. If you do not know the > > ISO code for your country, please complete with the full name of the > > country. > > The local IR could mention the local ISO3166 code here, or we could attach This is a good idea - I am not sure about adding the whole list of ISO codes to the package going out to people as it is quite long and from the requests I see, people get it right nearly all the time. > a > list of all (European) codes to the explanatory section. > > > Format: ISO 3166 two letter country code in CAPITAL LETTERS > > > > Example - country: IE > > > > admin-c: > > Please complete with the name or NIC handle of the person who is > > the administrative contact for the network. The NIC handle (if > > known) is preferred. > > > > Format: or the NIC handle if > > known. > > > > Example - admin-c: John E Doe > > This is a very detail and may better be discussed elsewhere, but if you pre > fer > "John E Doe" to "John E. Doe", this should more clearly be pointed out. > The requestor should be guided to leave out titles like 'Dr.' here, too. Also incoporated. > > > tech-c: > [...] > > > PERSON TEMPLATE NOTES > > > > Please ensure that you complete as many person templates as there are > > different persons specified in the network template unless the data > > about those persons is already in the RIPE database. > > [...] > > > address: > > Please complete with the full postal address. Include everything > > necessary for paper mail to be delivered. > > > > Format: multiple lines of text. City and post code on a single > > line. Country on the last line. > > > > Example - address: Terabit Labs Inc. > > address: Industrial Estate North > > address: North Perpendicular Road 12 > > address: NN-1234 Northtown > > address: Repubic of Northern Nowhere > > This may also be more appropriate on the db-wg list, but I remember some > rumors, that the 'country' attribute would be added to the person object .. > . This is not yet fully agreed right? In which case it is probably best left until a consensus has been reached on this in the db-wg. > > > phone: > > [...] > > > PART B > > ------ > > > > Information supplied below helps us to evaluate and process your request. > > > It will be kept in strict CONFIDENCE and NOT entered into the RIPE Networ > k > > Management Database. > > > > req-typ: > > This refers to the "request type". Please specify the quantity > and > > > class of your request for network numbers. > > > > 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) > > The numbers should read 254 * n and the info-sheet should explain why. Done. > > Nice to see this 32-C-block here ... > > > a single class B number (class B requests may be referred to the > > RIPE NCC for adjudication) > > other (please specify) > > This could make requestors switch over to contacting RIPE NCC direct for > class B requests. I think we do not want this happen, so better say it > unambigously. I have added the following which I hope will make this clear.. "a single class B number (class B requests may be referred to the RIPE NCC for adjudication. Please do NOT make your application direct to the RIPE NCC as it will only be forwarded to the local registry)." > > > provider: > [...] > > > 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. I think you are right - the term "host" does cause confusion. Maybe it is better simply to drop the term and use something like "machine-0" instead. So then we have machine-0: Please state the number of machines in your organisation that currently require a unique IP network number including terminal servers.. Mentioning PC's should could also be confusing as people also might think that *every* PC on the network should be counted... > > > Format: complete with a number. > > > > Example - host-0: 100 > > > > host-1: > [...] > > > sub-0: > > Please state the number of subnets required for the current network. > > A subnet refers to the physical parts of the network which need a > > unique (sub)net number. > > It is a very good idea to ask for this information, as it is really missing > to date and we have to call the requestor for it every now and then. > It could also prevent people from just copying the host numbers from the re > q-typ > field into the host-? fields, which may happen if the host number seems to > be > the only figure of interest. ["How many hosts do I need to have for receivi > ng > a class B address?"] > > > Format: complete with a number. > > > > Example - sub-0: 10 > > > > sub-1: > > Estimate the number of subnets in one years time. > > > > Format: as above. > > > > sub-2: > > Estimate the number of subnets in two years time. > > > > Format: as above. > > 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 overvie > w > 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 num > ber > of regional offices. This is a good point and if incorporated could eliminate quite a lot of the further clarification we often require when large blocks are requested - it would help us ascertain whether the address space is being used efficiently. We could incorporate it into the Section D where people are asked to give a description of their network plans. Equally we could point out in the preamble of Section D not to forget their transit networks when calculating their needs. > > > ip-prov: > [...] > > > use-net: > > Please answer the question - has your organisation already obtained > > an IP network number or numbers? If so, please give the network > > number(s). If not, then please complete with . > > > > Format: complete with the network number only - four numbers > > separated by dots, as shown below. > > > > Example - use-net: 193.87.45.0 > > or > > Example - use-net: > > For easier error detection/consistency checking the network name could > additionally be mentioned, if possible, i.e. if known. > This could work - providing people specify exactly the same network name as they have in the database. Otherwise it is not really of much use. Again, it must not be confused with the DNS names. I have incorporated it for the time being. See what other people think. > > iso-net: > > [...] > > > Part D: > > ------ > > > > If you are applying for more than 2 Class C network numbers then > > on a separate page, please submit a description of your network plans. > > The more numbers you are requesting, the more detailed your technical > > description will need to be. Furthermore, the more detail you provide, > > the quicker we will be able to process your application. > > > > Please read the supporting documentation (currently under preparation) > > which will guide you. It is particularly important to read this document > > > if you are applying for a class B network number, as it provides a number > > > of helpful hints. It is available from: > > > > > Please consider the following in your description: > > It is always a good idea to ask requestors for B addresses what subnet mask > they want to apply. > > > Current network layout: > > Future network plans: > > just my 2 cents ... Many thanks for your useful comments. I'll put a second draft out soon. Regards, Anne. > > regards, > Peter From D.Rogerson at nosc.ja.net Wed Dec 9 15:06:05 1992 From: D.Rogerson at nosc.ja.net (Duncan Rogerson) Date: Wed, 9 Dec 1992 14:06:05 +0000 (GMT) Subject: First draft of the European Template for IP number requests Message-ID: <9212091406.AA22622@tarquin.ja.net> > The local language version is something to be composed by the local > NICs which explains how to fill in the form. > This was agreed at the ir-registry BOF in Paris wasnt it? Yup, I think it was. This is a good idea, so in the cases where it's more appropriate for another NIC to handle the allocation, it's simple for them to deal with the form. > a drag..) This form is actually designed so as to be difficult to > fill in *without* reading the documentation - quite carefully - first. This is the bit I don't like, I think this is a bad idea. I think the people that are reasonable enough to take the time out to read accompanying documentation will do that even if the form is apparently easy to fill in at first sight. There are always going to be people who `know better' and just do it. > BUT I do think you run the risk of getting information back to you in a > format that will require quite a bit of massaging.. and is possibly > incomplete. I guess it is personal taste, but short field names and reams of documentation strike me as another good way of getting incomplete info back ... > The template is built around the idea of the RIPE database wich includes > explanations on how to fill in each field and this seems to be understood Yeah, but the RIPE database is largely used by folks acquainted with the networking field - Joe User who has just opened his Sun workstation manual which tells him to go get an IP number isn't. (We've had several people telling us they need at least 255 network numbers, when what in fact they do mean is they need 255 host addresses, for example). Sorry to sound so down on this, but I really would be loathe to start sending this style of form out. Most of the requests we deal with at ULCC are NIC of last resort queries (ie people who are not going to connect to the Internet at large). Many of them are not fully acquainted with the Internet, and I think we will just confuse them further. If we could design a form where the responses were in the same place, regardless of language, eg by using the database template idea, but supplying information along with it, I think it'd be better. Dunc From Havard.Eidnes at runit.sintef.no Wed Dec 9 21:00:30 1992 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Wed, 9 Dec 92 21:00:30 MET Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Fri, 04 Dec 92 11:17:38 N Message-ID: > > 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 From Marten.Terpstra at ripe.net Thu Dec 10 09:24:09 1992 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 10 Dec 92 09:24:09 +0100 Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Wed, 09 Dec 92 21:00:30 +0700. Message-ID: <9212100824.AA19750@ncc.ripe.net> Havard.Eidnes at runit.sintef.no writes: * > > Format: quantity of numbers requested followed by class of req * uest. * > > * > > 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%. Not quite sure what you mean here. What do you consider the best utilization of a subnetted class C address ? If you split up the C net in 32 hosts parts (actually 31), you loose hostnumbers 0,32,64,96,128,160,192,224 and 255 (which is 9 hostsnumbers out of 255 ~ 3.5%). With two large subnets you loose hostnumbers 0,128 and 255 which is around 1%. The only thing is that you will have to convince people to pack their network numbers as good as possible. * It is good to see that the number of subnets is asked for. Exactly, and I think that the mix of number of hosts and subnets is a good indication for the registries to base the assigments on. I do not think that one should simply give whatever they ask for. We have had more than one case where people had 1500 hosts on 50 subnets and asked for 50 class Cs. You really want these people to only use up 8 or maybe 16 Cs. Besides if you compare the hosts and subnet predictions together with the number of nets they request, you get a fair idea whether of not they have any idea what they are doing ;-) -Marten From pmk at deins.informatik.uni-dortmund.de Thu Dec 10 10:05:17 1992 From: pmk at deins.informatik.uni-dortmund.de (Peter Koch) Date: Thu, 10 Dec 92 10:05:17 N Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Thu, 10 Dec 92 09:24:09 +0100. <9212100824.AA19750@ncc.ripe.net> Message-ID: <9212100905.AA28714@meins.informatik.uni-dortmund.de> Marten.Terpstra at ripe.net writes: > Havard.Eidnes at runit.sintef.no writes: [...] > * I have for a while looked at these host numbers as somewhat inaccurate, > * primarily since this does not take subnetting into account. If you subne t > * a class C network number (as some people end up doing, as was mentioned b y > * Peter Koch, since sometimes people have a small number of hosts at a give n > * 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 ma ke > * 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%. > > Not quite sure what you mean here. What do you consider the best utilization > of a subnetted class C address ? If you split up the C net in 32 hosts parts > (actually 31), you loose hostnumbers 0,32,64,96,128,160,192,224 and 255 > (which is 9 hostsnumbers out of 255 ~ 3.5%). With two large subnets you loose > hostnumbers 0,128 and 255 which is around 1%. The only thing is that you will > have to convince people to pack their network numbers as good as possible. If you have the need for two large subnets, you have to use a mask of 2:6 (see below). This is bad, we have in some cases seen subnets of size 50-70 and then had to assign one C address for each of them. If you actually use subnetting 3:5, you have 2^3-2=6 subnets with 2^5-2=30 hosts each. You have a maximum of 180 hosts here (router(s) not taken into account), an unsubnetted network would offer 254, so this is about 71 %. Looking at all possible subnet masks, you get: subnet mask | # subnets | # hosts/subnet | total # hosts | usage -------------+------------+----------------+---------------+------ 1:7 | not allowed| | | 2:6 | 2 | 62 | 124 | 49 % 3:5 | 6 | 30 | 180 | 71 % 4:4 | 14 | 14 | 196 | 77 % 5:3 | 30 | 6 | 180 | 71 % 6:2 | 62 | 2 | 124 | 49 % 7:1 | not allowed| | | Percentage is nothing to worry about too much. More address space would be wasted if you would assign a full class C net for every subnet the requestor operates. > * It is good to see that the number of subnets is asked for. > > Exactly, and I think that the mix of number of hosts and subnets is a good > indication for the registries to base the assigments on. I do not think that > one should simply give whatever they ask for. We have had more than one case > where people had 1500 hosts on 50 subnets and asked for 50 class Cs. You > really want these people to only use up 8 or maybe 16 Cs. Besides if you > compare the hosts and subnet predictions together with the number of nets > they request, you get a fair idea whether of not they have any idea what they > are doing ;-) Agreed. Peter From Marten.Terpstra at ripe.net Thu Dec 10 11:08:03 1992 From: Marten.Terpstra at ripe.net (Marten Terpstra) Date: Thu, 10 Dec 92 11:08:03 +0100 Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Thu, 10 Dec 92 10:05:17 +0100. <9212100905.AA28714@meins.informatik.uni-dortmund.de> Message-ID: <9212101008.AA19924@ncc.ripe.net> "Peter Koch" writes: * * Marten.Terpstra at ripe.net writes: * * > Havard.Eidnes at runit.sintef.no writes: * * [...] * If you have the need for two large subnets, you have to use a mask of 2:6 * (see below). This is bad, we have in some cases seen subnets of size 50-70 * and * then had to assign one C address for each of them. * * If you actually use subnetting 3:5, you have 2^3-2=6 subnets with * 2^5-2=30 hosts each. You have a maximum of 180 hosts here (router(s) not ta * ken * into account), an unsubnetted network would offer 254, so this is about 71 * %. * * Looking at all possible subnet masks, you get: * * subnet mask | # subnets | # hosts/subnet | total # hosts | usage * -------------+------------+----------------+---------------+------ * 1:7 | not allowed| | | * 2:6 | 2 | 62 | 124 | 49 % * 3:5 | 6 | 30 | 180 | 71 % * 4:4 | 14 | 14 | 196 | 77 % * 5:3 | 30 | 6 | 180 | 71 % * 6:2 | 62 | 2 | 124 | 49 % * 7:1 | not allowed| | | * * Percentage is nothing to worry about too much. * More address space would be wasted if you would assign a full class C net * for every subnet the requestor operates. Sorry about my fantastic calculations. You are of course right. I'll make sure I get some more coffee next time ;-) * Peter -Marten From daniel at digsys.bg Thu Dec 10 14:18:41 1992 From: daniel at digsys.bg (Daniel Kalchev) Date: Thu, 10 Dec 92 14:18:41 EET Subject: First draft of the European Template for IP number requests In-Reply-To: <9212100905.AA28714@meins.informatik.uni-dortmund.de>; from "Peter Koch" at Dec 10, 92 10:05 am Message-ID: <9212101418.AA17655@digsys.bg> > Looking at all possible subnet masks, you get: > > subnet mask | # subnets | # hosts/subnet | total # hosts | usage > -------------+------------+----------------+---------------+------ > 1:7 | not allowed| | | > 2:6 | 2 | 62 | 124 | 49 % > 3:5 | 6 | 30 | 180 | 71 % > 4:4 | 14 | 14 | 196 | 77 % > 5:3 | 30 | 6 | 180 | 71 % > 6:2 | 62 | 2 | 124 | 49 % > 7:1 | not allowed| | | Just one probably silly question - why should the subnet mask 1:7 not be allowed? If I get it right, you speak of netmask like 255.255.255.128. Which should let you have two subnets of 126 hosts each. Daniel From pmk at deins.informatik.uni-dortmund.de Thu Dec 10 14:31:44 1992 From: pmk at deins.informatik.uni-dortmund.de (Peter Koch) Date: Thu, 10 Dec 92 14:31:44 N Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Thu, 10 Dec 92 14:18:41 +0700. <9212101418.AA17655@digsys.bg> Message-ID: <9212101331.AA29076@meins.informatik.uni-dortmund.de> > > Looking at all possible subnet masks, you get: > > > > subnet mask | # subnets | # hosts/subnet | total # hosts | usage > > -------------+------------+----------------+---------------+------ > > 1:7 | not allowed| | | > > 2:6 | 2 | 62 | 124 | 49 % > > 3:5 | 6 | 30 | 180 | 71 % > > 4:4 | 14 | 14 | 196 | 77 % > > 5:3 | 30 | 6 | 180 | 71 % > > 6:2 | 62 | 2 | 124 | 49 % > > 7:1 | not allowed| | | > > Just one probably silly question - why should the subnet mask 1:7 not > be allowed? If I get it right, you speak of netmask like 255.255.255.128. Your interpretation is correct. The mask 1:7 (as 7:1) is not allowed according to the recommendation to use all zeroes and all ones *neither* in the host part, *nor* in the subnet part. >From RFC1009 [Requirements for Internet gateways], page 6: RFC1009> The bit positions containing this extended network number are RFC1009> indicated by a 32-bit mask called the "subnet mask" [21]; it is RFC1009> recommended but not required that the bits be RFC1009> contiguous and fall between the and the RFC1009> fields. No subnet should be assigned the value RFC1009> zero or -1 (all one bits). > Which should let you have two subnets of 126 hosts each. Similar reasons might have lead to the following B) In order to prevent implementation problems, network numbers ending with 0 or 255 should NOT be reassigned. found in ripe-72.txt . Just walking off the topic ... Peter From Daniel.Karrenberg at ripe.net Thu Dec 10 15:38:31 1992 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 10 Dec 92 15:38:31 +0100 Subject: Confusion about Network Number Assignments! Message-ID: <9212101438.AA20550@ncc.ripe.net> Dear NIC people, some of our local registries are getting confused about recent direct network number assignments from nic.ddn.mil. Below you see the third message of the kind this week. I have sent you a list of the countries we cover on July 24th. Is there any special reason for this? In order to clarify things even further I append two lists. The first is the list of countries we definitely cover. Please do not assign network numbers for use in these countries! This defeats route aggregation (CIDR) and causes considerable confusion. The second list is a list of countries which have ties to RIPE or countries within RIPE. These ties very frequently cause common networking activities in these countries and countries within RIPE. In such cases RIPE and the RIPE NCC will be happy to coordinate and provide service if so requested. In short: we are willing to help with these on request either from you or someone within those countries. We will coordinate any registry activity concerning countries in the second list with you. If you have any questions about the list or the procedures or any particular case, please contact us at . We would also like to hear quickly if users have problems with local registries in our rewgion. Regards Daniel Karrenberg NCC Manager ------- Forwarded Message Date: Thu, 10 Dec 92 13:47:43 +0100 From: Nandor Horvath To: ncc at ripe.net Subject: Class C net number requests Dear Daniel and Marten, As far as I know the NIC told, that all the European IP number requests would be handeld by RIPE, and/or the appropriate national NIC. I get more and more requests to register domain names, but then they state, that they do not need network numbers, because they got it already. It turned out, that they all got it directly from the US NIC, the last such a response was signed by Jean Gallagher. Obviously the system, that if the US NIC gets a request from Europe, they would send it to the RIPE NCC, does not work properly. Any ideas? Nandor ------- End of Forwarded Message List of RIPE countries: AD ANDORRA AL ALBANIA AM ARMENIA AT AUSTRIA AZ AZERBAIJAN BA BOSNIA HERCEGOVINA BE BELGIUM BG BULGARIA BY BELARUS CH SWITZERLAND CS CZECHOSLOVAKIA CY CYPRUS DE GERMANY DK DENMARK EE ESTONIA ES SPAIN FI FINLAND FR FRANCE GB UNITED KINGDOM GE GEORGIA GI GIBRALTAR GR GREECE HR CROATIA (local name: Hrvatska) HU HUNGARY IE IRELAND IL ISRAEL IS ICELAND IT ITALY KZ KAZAKHSTAN LI LIECHTENSTEIN LT LITHUANIA LU LUXEMBOURG LV LATVIA MC MONACO MD MOLDOVA, REPUBLIC OF MS MONTSERRAT MT MALTA NL NETHERLANDS NO NORWAY PL POLAND PT PORTUGAL RO ROMANIA RU RUSSIAN FEDERATION SE SWEDEN SI SLOVENIA SM SAN MARINO SU USSR TJ TAJIKISTAN TR TURKEY UA UKRAINIAN SSR UZ UZBEKISTAN VA VATICAN CITY STATE (HOLY SEE) YU YUGOSLAVIA List of countries we are willing to help with: AE UNITED ARAB EMIRATES AN NETHERLANDS ANTILLES AW ARUBA BH BAHRAIN CI COTE D'IVOIRE DZ ALGERIA EG EGYPT FK FALKLAND ISLANDS (MALVINAS) FO FAROE ISLANDS GF FRENCH GUIANA GL GREENLAND IO BRITISH INDIAN OCEAN TERRITORY KW KUWAIT LB LEBANON MA MOROCCO OM OMAN PF FRENCH POLYNESIA QA QATAR SA SAUDI ARABIA SR SURINAME TF FRENCH SOUTHERN TERRITORIES TN TUNISIA VG VIRGIN ISLANDS (BRITISH) From Anne.Lord at ripe.net Thu Dec 10 15:56:53 1992 From: Anne.Lord at ripe.net (Anne Lord) Date: Thu, 10 Dec 92 15:56:53 +0100 Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Thu, 10 Dec 92 14:31:44 +0100. <9212101331.AA29076@meins.informatik.uni-dortmund.de> Message-ID: <9212101456.AA20602@ncc.ripe.net> > > found in ripe-72.txt . Just walking off the topic ... > I think so - valid but - somewhat off the main track of the discussion over the overall format of the proposed European IP forms. more soon... Anne. From Anne.Lord at ripe.net Thu Dec 10 16:24:16 1992 From: Anne.Lord at ripe.net (Anne Lord) Date: Thu, 10 Dec 92 16:24:16 +0100 Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Wed, 09 Dec 92 21:00:30 +0700. Message-ID: <9212101524.AA20707@ncc.ripe.net> > 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 From Havard.Eidnes at runit.sintef.no Thu Dec 10 17:32:38 1992 From: Havard.Eidnes at runit.sintef.no (Havard.Eidnes at runit.sintef.no) Date: Thu, 10 Dec 92 17:32:38 MET Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Thu, 10 Dec 92 09:24:09 +0100 Message-ID: I said: > * ...If you subnet a class C network number... 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%. and Marten Terpstra replied: > Not quite sure what you mean here. What do you consider the best utilization > of a subnetted class C address ? If you split up the C net in 32 hosts parts > (actually 31), you loose hostnumbers 0,32,64,96,128,160,192,224 and 255 > (which is 9 hostsnumbers out of 255 ~ 3.5%). With two large subnets you loose > hostnumbers 0,128 and 255 which is around 1%. The only thing is that you will > have to convince people to pack their network numbers as good as possible. Ok, lets do the arithmetic for these two cases: for a subnet mask of 0xffffffc0, you lose 0-63 (subnet zero) 192-255 (subnet "minus one") and 64, 127, 128, 191 (various broadcast addresses) which comes out to just under 50% utilization. With cisco routers, if you know what you are doing (!) you may say "subnet-zero", and use subnet zero as an ordinary subnet. This is not without danger. With a subnet mask of 0xfffffff0, you lose 0-15 (subnet zero) 240-256 (subnet "minus one") and 14*2 host numbers (0 and "minus one" for subnet broadcasts) which comes out to just under 77% utilization. > * It is good to see that the number of subnets is asked for. > > Exactly, and I think that the mix of number of hosts and subnets is a good > indication for the registries to base the assigments on. I do not think that > one should simply give whatever they ask for. We have had more than one case > where people had 1500 hosts on 50 subnets and asked for 50 class Cs. You > really want these people to only use up 8 or maybe 16 Cs. Besides if you > compare the hosts and subnet predictions together with the number of nets > they request, you get a fair idea whether of not they have any idea what they > are doing ;-) Yes, but with other (older) routing protocols than OSPF, this all depends on the (planned?) topology of the network, since you can't tie together subnets of a subnetted network with pieces of another network. - Havard From d.rogerson at nosc.ja.net Tue Dec 15 11:48:37 1992 From: d.rogerson at nosc.ja.net (Duncan Rogerson) Date: Tue, 15 Dec 1992 10:48:37 +0000 (GMT) Subject: First draft of the European Template for IP number requests Message-ID: <9212151048.AA06288@biffa.ja.net> > then it obviously won't be worth it. Might it be worth "piloting" various > types of forms?? This might be a nice idea, if we got a few forms together, and then at first see how much trouble it is for the local Registries to translate/transform each into a local language version, and then take it from there, trying to find guinea pig applicants who don't mind taking the time to comment on the forms ? Dunc From Anne.Lord at ripe.net Tue Dec 15 15:26:11 1992 From: Anne.Lord at ripe.net (Anne Lord) Date: Tue, 15 Dec 92 15:26:11 +0100 Subject: First draft of the European Template for IP number requests In-Reply-To: Your message of Tue, 15 Dec 92 10:48:37 GMT. <9212151048.AA06288@biffa.ja.net> Message-ID: <9212151426.AA01056@ncc.ripe.net> > Duncan Rogerson writes: > > then it obviously won't be worth it. Might it be worth "piloting" variou > s > > types of forms?? > > This might be a nice idea, if we got a few forms together, and then do you want to put your suggested form forward (pref. some kind of rework of the RIPE draft)?? > at first see how much trouble it is for the local Registries > to translate/transform each into a local language version, and > then take it from there, trying to find guinea pig applicants who > don't mind taking the time to comment on the forms ? or we could use the RIPE audience at Prague .. > > Dunc > Anne From pmk at deins.informatik.uni-dortmund.de Fri Dec 18 10:38:00 1992 From: pmk at deins.informatik.uni-dortmund.de (Peter Koch) Date: Fri, 18 Dec 92 10:38:00 N Subject: First draft of the European Template for IP number requests Message-ID: <9212180938.AA20820@meins.informatik.uni-dortmund.de> Just as a support for PR actions we could ask requestors how they managed to contact the local IR or RIPE-NCC, i.e. where they got the address from. Of course this question is optional and we might increase the chance of getting answers if we ask in a multiple choice manner. XX. If this is the first time you apply for an address, please tell us how you came to know about O received a pointer from RIPE-NCC (well, who or what made you contact RIPE-NCC ?) O USENET News O customer support/documentation O local dealer O computer magazine (pls specify: _____________) O other publication (pls specify: _____________) O ... -Peter- From ncc at ripe.net Mon Dec 21 17:05:16 1992 From: ncc at ripe.net (RIPE NCC Staff) Date: Mon, 21 Dec 92 17:05:16 +0100 Subject: seasons greetings Message-ID: <9212211605.AA06966@ncc.ripe.net> Dear colleagues, We would like to thank all of you for a year of splendid cooperation during the first 3/4 year of NCC operation and for all your support during 1992. We would like to wish you all a merry X-mas and the best wishes for all of you in 1993, and hope to continue the excellent cooperation in the coming year. Thank you all, Anne, Daniel and Marten From Lyman at BBN.COM Mon Dec 21 22:11:36 1992 From: Lyman at BBN.COM (Lyman Chapin) Date: Mon, 21 Dec 92 17:11:36 EDT Subject: seasons greetings In-Reply-To: <9212211605.AA06966@ncc.ripe.net> Message-ID: <9212221202.AA07978@ncc.ripe.net> >To: ripe at ripe.net >Subject: seasons greetings >Cc: local-ir at ripe.net, hostmaster at nic.ddn.mil, iana at isi.edu, all-staff at rare.nl, > ip-provs at ripe.net >From: RIPE NCC Staff >Date: Mon, 21 Dec 92 17:05:16 +0100 > > >Dear colleagues, > >We would like to thank all of you for a year of splendid cooperation during >the first 3/4 year of NCC operation and for all your support during 1992. > >We would like to wish you all a merry X-mas and the best wishes for all of >you in 1993, and hope to continue the excellent cooperation in the coming year. > >Thank you all, > >Anne, Daniel and Marten Anne, Daniel, and Marten, Watching from "across the water", I think you have been doing a splendid job - Merry Christmas indeed, and best wishes to you too! - Lyman Chapin