January 1996 - lir-wg - mailman.ripe.net

Announcement for Local IR Training Course in Paris
by RIPE NCC Training 26 Jan '96

26 Jan '96

* * * Announcement * * * Local Internet Registries Training Course Date: Monday, 26th February 1996 Time: 0900 - 1700 Venue: Hyatt Hotel Airport Charles de Gaulle Paris France Course Audience --------------- The target audience for this course is personnel of European Local Internet Registries that contribute to the RIPE NCC. Material Covered ---------------- The course is a one day introduction on Internet name, address and routing policy registration procedures in Europe. It also teaches how to query and use the information registered for operational purposes. This includes the following material and activities: o Overview of name, address and routing registration procedures. o Responsibilities of both RIPE NCC and Local IR's to each other. o Wider context of the Delegated Registry system and relevant issues (IPv4 address depletion, CIDR) and how this relates to IP requests. o How to use the RIPE NCC Database. o Use of AS numbers, Routing Registry concepts and an introduction to using PRIDE tools. o DNS feedback on commor errors, how to request delegations, and pointers to useful tools. We again stress that this course will *not* teach Local Registries on how to run their business as Internet Service Providers. It is clearly focussed on registration procedures and the interaction between the RIPE NCC and local IR's. A detailed outline is appended below. The course itself will include lunch and will be free. This of course does not include your travel and subsitence ;-). How to Register --------------- Please send an RSVP to <training(a)ripe.net> if you would like to attend the course. If you have previously approached us about attending this course, we ask you to confirm that you (or a colleague) will be attending. Registrations will be accepted on a first come, first served basis. If the course is oversubscribed, we will give priority to local IRs who have paid the signup fee in 1995. If it is still oversubscribed, we will accept only one person per new local registry. We will provide additional course dates in Amsterdam as necessary. If a number of local registries so request, we will present courses at other European locations. If you would like a local course or have any questions or suggestions, please do not hesitate to contact us. The RIPE NCC Training Team: Mirjam Kuehne, Daniel Karrenberg --- Course Outline -------------- For this second course, we will provide a slidebook and a reader on the day of the course, as well as electronically. Once feedback is received, it is planned to make detailed documentation available in the form of a guide much like the PRIDE guide. The program will divide the actual content into the following sections: 1. Introduction For those unfamiliar with the Delegated Internet Registry system and the RIPE NCC, this section will give a historical overview of how we have arrived at today's model of operation and why training of local IR's is a much needed activity. 2. IP Registry procedures This section will clarify the procedures between the RIPE NCC and local IR's with respect to requests for IP address space. It will take a step by step approach on how to complete documentation, the kind of information that is required, what the "handholding" procedure is, how to deal with very large requests, and very small requests, and more generally what criteria the RIPE NCC and local IR's use for their customers in the context of CIDR and IPv4 address depletion. 3. RIPE NCC Database This section will explain what the RIPE NCC Database is and how it fits into the scheme of other registry databases. It will cover how to create and update RIPE NCC Database objects and will explain how to query the database. 4. Routing Registry procedures This section will examine AS numbers, when you need them and how to request them. This will be set within the context of how AS numbers are used as part of the RIPE Routing Registry. Understanding the basic principles behind the Internet Routing Registry and how registering your policy is an important element in the global schema. This section will also include a brief introduction to the PRIDE tools and how they can be useful to you. 5. DNS procedures Where to request forward and reverse domain delegation. Which documentation should be completed. How reverse domain delegation requests are processed at the RIPE NCC (with a useful tool). We will also take a look at common errors in setting up DNS with respect to relevant RFCs and RIPE recommendations. Feedback Please! Throughout the course there will be ample chance for feedback and discussion with an emphasis for you to tell us how we can improve ;-). %%%%%%%%%%% PLEASE NOTE %%%%%%%%%%% Our handling of ALL course registrations is fully automated. To register for the course, please complete the registration form and send it to <training(a)ripe.net>. Please send only the registration form in your reply and edit out all other text. Add in a value in the `box' area marked between the square brackets (i.e. "[" and "]" s). If you have any questions about the training course or your registration form, please contact us at <training(a)ripe.net>. You will receive a notification message that your request has been processed. Many thanks, and look forward to seeing you, RIPE NCC Training Team ---------------------------------------------------------------------------- %START PART 1 - Registration 1) Your name Enter First name, Last name in FULL e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

Re: Policy Statement on Address Space Allocations
by Eric Kozowski 26 Jan '96

26 Jan '96

>If you really need it, a much more effective method to get short term relief >is to squeeze some of the "history" out of the forwarding table. The 192.* >block, and some of the high 190's, look like swamps that are ripe for the >picking. This is a though I've been mulling over for a while. Why not have the IANA set a "flag day" for the 192 space. Say, on 1 March 97, the 192.0.0.0/8 space will no longer be routable. At this point, the IANA, then sits on the space, now removed from the routing tables, and reassigns it at a later date. OR Just make 192.0.0.0/8 rfc1597 type of address space? Just a thought that would need more serious discussion to implement. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

1 0

Re: Policy Statement on Address Space Allocations
by Hakan Hansson 25 Jan '96

25 Jan '96

At 08:20 1996-01-25 -0500, Sean Doran wrote: > >> The same ISP has said publicly that they will route /19 prefixes in our >> address space: 193/8 and 194/8. The discussion is still going over >> future /8s. But read the last paragraph of the policy statement! > >Sure, there is no filtering in 193/8 and 194/8, >and as a result we have VERY poor aggregation. > >Consider this random cut-and-paste from 194/8. > >* 194.19.36.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i >* 194.19.37.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i >* 194.19.40.0 144.228.101.1 1 90 0 1239 701 3300 3301 5381 i [etc. etc.] Since, you have presented examples routed through 3300 I felt it was ok to comment this. We have experinced that customers of ours sometimes later purchased a connection from another ISP keeping the connection to us. Therefor will all allocation of address space to that customer no longer be aggregated by us. Even if we know that this customer in most cases has customers of his own, we usually don't reserve blocks for him. Well, you see the result in the routing table. I thought in the beginning of CIDR that I would never had to announce anything but 194.16/13. For connectivity reasons this is not possible. The only solution might be that every network that later becomes an AS has to renumber the complete network (and it's customers also). In addition to that he has to become a Local Internet Registry with his own address space. One AS, one registry.... /Hakan -- Unisource Business Networks Sweden -- Uniplus Internet Services * TIPnet NMC * Goteborg -- phone +46-31-7708072 * fax +46-31-7114664 -- PGP: http://dojan.tip.net/hh/PublicKey.htm

2 1

1st draft: proposed agenda - DB-WG at RIPE 23, Amsterdam
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

This is the 1st proposal of a draft agenda for the Database-WG at RIPE 23 in Amsterdam. **Message to the NCC WG scheduling department: If at all possible - please have the DB-WG meeting slot(s) scheduled near the end of the WG stream(s). Thank you! I'd propose to have 2 sessions, - one for the more formal items (A. - D., Y., Z.) and - another one for the more general aspects (E., F., G.). The "general aspects" session should probably precede the formal one. As always, additons, comments, etc. welcome! Apologies if I missed something obvious... See you, Wilfried. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Draft Agenda: Database-WG, RIPE 23, Amsterdam, NL ------------------------------------------------------ A. Administrative stuff - volunteering of the scribe - WG-agenda bashing B. DB-SW report - general status report - "realtime" shadowing - hierarchical authorisation for creation and update - backlink implementation - automatic handle assignment C. DB-Objects and attributes - referral mechanisms and distribution of authoritative data - stored/processed attribute (A: 19.12) - do we want/need a registry object? - mcast extensions for inet-rtr:, peer: attribute (A: ) - ROLE/NOC object, handling of lookup recursion - URL attribute? (credits for the idea to Erik-Jan Bos) D. Copyright for the RIPE-DB proposal to have every whois query return % data is copyrighted, and a pointer to the (C) definition of comment and/or meta-characters (%, #, *) ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ E. Databases and registries interoperation brainstorming about needs, methods,... the 192 review project by B.Manning quality control of data, duplicates alert, fuzzy matching... uniqueness of names across databases (AS macros, route) references to data in a different database common update mechanism for "all" databases (multiple source: values? auto forwarding?) proposal for a coordinated development project? F. User Interfaces Tools online documentation G. Authentication and security ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Y. Input from other WGs Z. AOB Draft 1.0, 23-JAN-1996 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

ripe-104++ - Summary of Policy Changes
by mnorris＠dalkey.hea.ie 25 Jan '96

25 Jan '96

The schedule of WG meetings at RIPE 23 has been posted and the two sessions I sought for the Local IR meeting are back-to-back on Monday afternoon. A meeting of the MBONE WG parallels the second session, so I propose to use the first session (14:00 to 15:30) solely for discussion of the ripe-104++ draft circulated on Monday (copies available at ftp://ftp.ripe.net/ripe/drafts/ripe-104++.[ps|txt] ) As mentioned before, the draft is neither complete nor thoroughly checked for syntax, typos etc. Leaving those aside, the plan is to discuss only the substantive policy issues on Monday. So I've tried to summarise the changes in policy and procedure as they affect RIPE, the local IRs and the ISPs. There's repitition and omission here, but it should serve as a draft guide for the debate. Btw, page numbers refer to the PostScript version. Cheers. Mike Norris ripe-104++ - Summary of Policy Changes -------------------------------------- 1. 2.2. Goals of Public Address Space Distribution (page 4) The goals of: Uniqueness Aggregation Conservation Registration are explicitly stated. 2. 2.4 Validity of assignment (page 7) Assignments of any kind of address space are valid as long as the original criteria on which the assignment was based are still valid. 3. 3. Address Space Assignment Procedures 3.2.1 Required Information (pages 9 to 17) The following set of information must be provided with every with every request for an address assignment. 3.2.1.1. Overview of Organization Contact Persons 3.2.1.2. Current Assignment Space Usage 3.2.1.3. Request Overview Size of Request Addresses to be Used Number of Subnets Internet Connection Country Private Address Space Request Refused PI Requested 3.2.1.4. Addressing Plan 3.2.1.5. Database Information Organization Personal Data 3.2.2. Additional Information Deployment Plan Topological Map Special Circumstances Verification Information 4. 3.3. Evaluation (pages 17 to 19) Every request requires an individual evaluation process that takes current assignment guidelines into account. In the process, it is essential that IR's work to prevent the stockpiling of address space. Meanwhile, to enable proper routing, one must make strategic decisions with regard to aggregation. Evaluation Steps 1. Current address space usage 2. Network Overview 3. Private Address Space 4. Very Small Enterprises (VSE's) 5. Addressing Plan 6. Additional Information 7. Address Reservations 8. Static Dialup 9. Virtual Hosts 3.4. Assignment Procedures 3.4.1. Assignments within Allocations (page 19) Specifically, each set of address space assigned should start on a CIDR (bit) boundary. 3.4.2. PA vs PI Space (pages 20 to 22) Clear contractual arrangements which specify the duration of the address space assignment are mandatory for every assignment of PA address space. Although not strictly required, it is strongly recommended that contractual arrangements are made when assigning PI space as well. The consequences of using PA or PI space must always be made clear to the end user. Assignment of this (PA) address space is valid as long as the criteria for the original assignment are still met and only for the duration of the service agreement between yourself and ISP XXXX. Every new address space assignment must be marked as PA or PI in the RIPE database. Any assigned address space without an explicit type in the status attribute is assumed to be PI space. Formally, address space is not of type PA unless there are contractual agreements regarding the assignment's termination. It is therefore recommended that IRs ask end users to release non-PA address space upon termination of service. 3.5. Assignment Window (page 24) The assignment window is the maximum number of addresses that can be assigned by the local IR to an end user without prior approval by the RIPE NCC. Currently, the maximum size of the assignment window for any local IR is 4096 addresses (/20). If such errors are noticed by the RIPE NCC, the assignment window for the local IR may be decreased to prevent the staff from making erroneous assignments involving a substantial amount of address space. 4. Rules and Guidelines for Allocations (page 26) If a local IR allows another IP service provider to make an assignment from its allocated address space, the local IR is still responsible to guarantee the assignment is made according to the guidelines specified in this document. 4.1. Slow Start of Allocations (page 26) The minimum allocation is /19 (8192 addresses). The maximum size of an individual allocation is /16 (65536 addresses). The size of allocations is based solely on the rate that previously allocated address space has been assigned to end users. 4.2. First Allocation (page 27) The first allocation will be made automatically by the RIPE NCC, generally upon receipt of the first assignment request from the local IR. Because there is no information about the rate at which a new IR will make address assignments, the size of the first allocation is always set at the minimum. 4.3. Further Allocations (page 27) Additional address space will be allocated after the information delivered with the request has been verified, and a new allocation has been deemed necessary. While the RIPE NCC always aims to further the aggregation goal, and therefore to allocate contiguous space, the RIPE policy is that under no circumstances are multiple allocations made to the same local IR guaranteed to be contiguous. 4.4. Allocation Registration (page 28) ALLOCATED UNSPECIFIED This address space has been allocated to an IR, and assignments made from it may be either provider aggregatable or provider independent. This type of allocation is obsolete, and will not be applied to future allocations. Some older allocations have been used for both PA and PI assignments, and as such receive this allocation type.

1 0

Policy Statement on Address Space Allocations
by Daniel Karrenberg 25 Jan '96

25 Jan '96

> Tony Li <tli(a)cisco.com> writes: > > To be more specific, the RIPE NCC has been using a policy such that it will > (at most) grant a prefix one bit shorter than the prefix that has been > used. Under this policy, it would be reasonable to ask for a /17, tho I'm > not saying that you necessarily can prove the growth to support it. I wonder where that rumour comes from. It is certainly not the RIPE NCC allocation policy. this is a good time to set the record straight on this and related things. This is *not* an attack on Tony who, I am sure, was quoting some rumour in good faith. Our basic allocation policy is: 1) The initial allocation for a newly established local registry (ISP) *always* is a /19. There will be no discussion about this. This is fixed, cast in stone, immutable, ... you get the idea. In particular it will not be influenced by marketing predictions, amount of capital available or the shoe size of the lawyers visiting our offices. (NB: The value of /19 might change at some point, but the fact that every newly established registry gets *the same size* initial allocation will not.) The reason for this policy is to avoid very lengthy, fruitless and frustrating discussions about the size of initial allocations which end up in expensive (in time and nerves) but basically arbitrary decisions. 2) After the initial /19 further allocations will depend *solely* on the usage rate of the particular registry. These allocations can currently be *anywhere* from /19 to /16 depending on the usage rate. Supernational registries may under certain conditions have more than one /16 allocation. The established usage rate is an objective criterion to determine the sizeof further allocations and our experience shows that we have very few discussions about allocation sizes. Now, as Forrest points out, this makes it desirable for each ISP to have a high usage rate. So local registries may be tempted to use more than needed. This is where the assignment policies come in to make sure that the conservation goal is respected. After all the usage rate is determined by *valid* assignments only. Our assignment policies and procedures provide strong incentives for registries to act prudently and and correctly. Note that we make /19 allocations even though one particular ISP is telling the world that /18 is the minimum you ought to have these days. Our experience suggests that /18 is too much to assign to any newly established local registry. It is too wasteful. On the other hand we cannot live without policy #1. So we decided to stick to /19s. The same ISP has said publicly that they will route /19 prefixes in our address space: 193/8 and 194/8. The discussion is still going over future /8s. But read the last paragraph of the policy statement! It should be noted that additional allocations are very often aggregatable with previous ones. So the number of /19 prefixes announced will decrease over time. I personally expect that we can reach *very* acceptable aggregation levels and current statistics support that: Routing Table router: amsterdam.ripe.net time: Mon Jan 22 11:06:13 1996 Destinations: 32934 Routes: 32934 /8 block hosts routes hosts addres- / sed route 192.0.0.0 4981504 6551 760 193.0.0.0 9264640 2019 4588 194.0.0.0 7665920 1849 4145 195.0.0.0 256 1 256 196.0.0.0 731648 329 2223 197.0.0.0 256 1 256 198.0.0.0 7488000 3705 2021 199.0.0.0 8838144 3338 2647 200.0.0.0 4660736 697 6686 201.0.0.0 256 1 256 202.0.0.0 4258496 1460 2916 203.0.0.0 5831424 780 7476 204.0.0.0 10499072 3660 2868 205.0.0.0 6019584 1793 3357 206.0.0.0 10967808 1649 6651 207.0.0.0 1019136 37 27544 C Space 82226880 27870 2950 It should be noted that we have started allocating hierarchically from 193/8 when the InterNIC was still using 192/8. So we feel that we have quite a good track record concerning routing aggregation and address space conservation too. We consider our policy a good compromise between aggregation and conservation and our community backs this policy. Daniel Karrenberg RIPE NCC Manager

2 1

Policy Statement on Address Space Allocations
by Daniel Karrenberg 25 Jan '96

25 Jan '96

------- Forwarded Message Date: Wed, 24 Jan 1996 15:46:05 -0800 From: postel(a)ISI.EDU To: nanog(a)merit.edu, cidrd(a)IEPG.ORG, iepg(a)IEPG.ORG, iab(a)ISI.EDU, iesg@ISI .EDU cc: iana(a)ISI.EDU, netreg(a)internic.net, ncc(a)ripe.net, hostmaster(a)apnic.net Subject: Policy Statement on Address Space Allocations Policy Statement on Address Space Allocations ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Regional Internet Registries (APNIC, InterNIC, RIPE NCC) refer organizations requesting IP address space to their Internet service providers (ISPs). This is done for various reasons, the main reason being that IP addresses need to be assigned hierarchically to allow aggregation of routing information (CIDR). Customers are warned of possible routing restrictions if addresses are not received from an ISP's CIDR block. Since some ISPs are presently restricting the length of prefixes they route, it is even more important for end users to receive IP addresses from their Internet service provider. Regional Internet registries have no control over the routing policies of any ISP. The IANA has instructed the Internet registries not to assign IP addresses based on any ISP's particular routing policy, rather on specific criteria including utilization efficiency. An organization will be assigned the number of IP addresses it can justify. If this number is not fully routable, that is an issue that should be taken up with the ISP(s) concerned. Regional Internet Registries inform ISPs about allocation and assignment policies. This enables ISPs to take these policies into account when setting their routing policies. s/ IANA, Internic, RIPE-NCC, AP-NIC. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ------- End of Forwarded Message

1 0

Re: ripe-104++
by Wilfried Woeber, UniVie/ACOnet 25 Jan '96

25 Jan '96

>- One address for a router >- One address for a Web-Server >- One address for a firewall >- up to 5 additional addresses for "other purposes". >In such cases, they will be allocated 8 or 16 addresses, > ( netmask 240 or 248 ). Neither is this situation, nor in the case depicted later, I do see a case for a full-blown assignment transaction. I would assume that the ISP connecting that web server has the addressesd assigned and manages the adress(es) needed to configure the technical stuff. And assuming that you've got more than one server to support, *you* might want to do an addressing plan and some assessment of your network development.... And if you decide to formally tell your customer about the individual address from your assignment to be used, then this can be seen as local matters. There's a difference, of course, if your're talking about a VSE with a LAN (IP based) that gets connected and might decide to become dual-homed... Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Vienna University : Tel: +43 1 4065822 355 Universitaetsstrasse 7 : Fax: +43 1 4065822 170 A-1010 Vienna, Austria, Europe : NIC: WW144 --------------------------------------------------------------------------

2 1

ripe-104++ too big!
by Carol Orange 24 Jan '96

24 Jan '96

Hi again, Unfortunately, not everyone received the document I sent out Monday because it's too big for some mailers. Sorry about that. If you fall in this category, you can pick up the document in: ftp://ftp.ripe.net/ripe/drafts/ripe-104++.ps or ftp://ftp.ripe.net/ripe/drafts/ripe-104++.txt Happy reading, -- Carol PS: Here is the letter which introduced the document: ------------------------------------------------------------------ Dear Local IR Working Group, The document included below is the first part of a document intended to replace ripe-104 and ripe-105. While we have made progress on the latter half, it is not ready for review. You can see what will be covered there if you read Section 1. This will be the background for the discussion mentioned by Mike Norris for the Local IR working group meeting next week. A number of people, most notably Mike Norris, Wilfried Woeber and Janos Zsako, have made useful comments and contributions to the draft below. Any remaining problems are, however, the responsibility of the authors. While our aim was to write down current practices, we understand that it may raise questions about policy. That's why we want to get it out to you before the RIPE meeting next week. Any errors you note can be sent directly to me (orange(a)ripe.net). I look forward to meeting you all next week. -- Carol

1 0

Re: ripe-104++
by saliba＠inco.com.lb 24 Jan '96

24 Jan '96

I agree with alain, I am also an ISP and I have many customers that require one IP address for their web server, so how to manage these requests. For the moment I think that I have to assign my first customer who is waiting for his web address since the beginning of January, a full IP Network number!! Do you have any other idea on how to do it? Regards, Therese > From ripe.net!owner-local-ir Tue Jan 23 22:58:39 1996 > Date: Tue, 23 Jan 1996 21:27:25 -0600 (CST) > From: Alain Golan <alain(a)NetVision.net.il> > To: Carol Orange <orange(a)ripe.net> > Cc: local-ir(a)ripe.net > Subject: Re: ripe-104++ > Mime-Version: 1.0 > > > There is an increasing number of entities requiring > very small address space, I.E. > > - One address for a router > - One address for a Web-Server > - One address for a firewall > - up to 5 additional addresses for "other purposes". > > In such cases, they will be allocated 8 or 16 addresses, > ( netmask 240 or 248 ). > > Requesting written "Additional information" or justification , > from the customer for a first allocation of 16 PA address space, > make us (LIR) a bit ridiculous, and is overloading. > > A telephone conversation like: > > LIR - Helo Mr Joe, > > Joe - Helo NetProvider > > LIR - I understand that you are connecting to our services, > and would like to setup addresses for You, what do you plan > to connect to the Internet ? > > Joe - Oh, I'll be running a web site for our skate-boards factory. > > LIR - And, are you going to connect other computers to the net ? > > Joe - not now, maybe next year I'll setup a mail gateway to > our novell mail system. > > LIR - Anything else in mind for the next two years ? > > Joe - no, the administration don't want our internal network > connected to the internet for security reasons. > > LIR - Do you understand that I will allocate you 6 addresses, > and that if you change your mind, and need more, you will > have to change the addresses of those 6 hosts ? > > Joe - Yes, but actualy it's only the web ... it's okay ! > > LIR - Is your company connected or connecting the Internet > somewhere else ? > > Joe - no, we don't have offices anywhere else. > > LIR - Thanks. > > --------------------------- > > Such a convertation is more realistic and saving more address > space than sending the requested-info form. > > -If Joe had filled the form, he would have probably asked for > more than 8 addresses. > > -For Joe to fill the form, LIR should have: > > - Faxed explanation documents in addition to the person > template. > - spent a lot of time explaining what are the fields. > > > It seems reasonable to me that if a request meet the following: > 1) FIRST - First address allocation for this entity > 2) PA - Provider Agregate > 3) Less or equal to 8 (or 16 ?) ip addresses limit. > 4) Connecting to the internet immediatly. > > The address space will be allocated without getting & > filling a deployment plan and justification. > > Does it make sense ? can it be accepted formally ? > > (I understand that it is not the current policy). > > > \Alain. > > > >

1 0