From stephenb at uk.uu.net Fri Sep 1 11:52:21 2000 From: stephenb at uk.uu.net (Stephen Burley) Date: Fri, 01 Sep 2000 09:52:21 +0000 Subject: [Robert.Kiessling@de.easynet.net: RE: SLA's needed !!!] References: <009EF6E2.69B3F8D0.6@cc.univie.ac.at> <20000831181511.K22921@Space.Net> <39AF6CE2.7BCF5B2@uk.uu.net> <20000901100554.N22921@Space.Net> Message-ID: <39AF7C55.93FCBA38@uk.uu.net> Hi I think alot of what has been said hold alot of water but lets not let the ideas get lost in the frustration. If you could hold your thoughts till the RIPE meeting the LIR working group in particular, then the May17th Task Force has a presentation with suggestions we would like the communty to adopt and would really go a long to solving hte current problems. -- Regards, ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life [SB855-RIPE] if you're stupid and willing to wait" ------------------------------------------------------------------------ From andrei at ripe.net Fri Sep 1 13:07:08 2000 From: andrei at ripe.net (Andrei Robachevsky) Date: Fri, 01 Sep 2000 13:07:08 +0200 Subject: Is this normal behaviour? References: Message-ID: <39AF8DDC.A06CDE3B@ripe.net> Hi, Marco Davids wrote: > > Hello, > > A routine check on as-macro AS-EURONET on the RIPE-database returned an > unexpected result. > > The same check on the RADB whoisd (whois.raddb.net) however, returned the > expected result together with two unexpected ones. > > Investigation learned us that someone deleted an unprotected as-macro on > the RIPE-database. It seems it is fixed now. > > But what I would like to know is to what extend the several whois > databases a synchronised, in other words; how reliable is the information > retrieved from it? And... is the as-set object supposed to be unique or > not? Currently RIPE whoisd server doesn't mirror RADB. The reason for this is that RADB is a RPSL database while the RIPE one is not (yet). However mirroring a database does not mean that integrity, auth, etc. checks are performed across the databases. That's why, though according to RPSL as-set attribute is a class key and should be unique, the query result contains 3 objects (but all from different databases/sources). Regards, Andrei Robachevsky DB Group Manager RIPE NCC > > -- > Marco Davids / SARA - Academic Computing Services Amsterdam > > Today's tip: ftp://ftp.ripe.net/rfc/rfc1925.txt -- From graham at nsl.net Fri Sep 1 13:03:29 2000 From: graham at nsl.net (Graham Burke) Date: Fri, 1 Sep 2000 12:03:29 +0100 Subject: Question In-Reply-To: References: Message-ID: <00090112142001.00781@tabitha.nsl.net> Hi just a quick question We have been recently been allocated our /19 however RIPE have assigned us only the first 700 address this I believe is pretty standard procedure. However our connectivity supplier will not advertise our routes unless we have our full /19 assigned and registered with RIPE, obvioulsy as the range is too small. Is there any other way around this problem other than getting RIPE to register our full /19 reserved pre-allocation, if not how do RIPE stand on registering the full /19????? Hope this makes sense thanks in advance Graham GB-10488 Network Sys Admin -- NSL (Internet) Ltd, 26 Forth Street, Edinburgh, EH1 3LH, UK http://www.nsl.net From joshua at roughtrade.net Fri Sep 1 13:42:53 2000 From: joshua at roughtrade.net (Joshua Goodall) Date: Fri, 1 Sep 2000 13:42:53 +0200 (CEST) Subject: Question In-Reply-To: <00090112142001.00781@tabitha.nsl.net> Message-ID: On Fri, 1 Sep 2000, Graham Burke wrote: > Hi just a quick question > We have been recently been allocated our /19 however RIPE have > assigned us only the first 700 address this I believe is pretty > standard procedure. > > However our connectivity supplier will not advertise our routes unless > we have our full /19 assigned and registered with RIPE, obvioulsy as > the range is too small. Graham, Your transit provider is almost certainly in error. Unless you are asking them to route individual prefixes to places other than your network, it is simply a matter of them announcing your /19 at their border. Then you can run an IGP (e.g. OSPF) with them, placing you inside their AS. Alternatively you could speak BGP to them using a private AS that is stripped before public announcement. Finally, if you are multihomed, you can apply for an AS number and simply announce your prefix using standard BGP. Implementing this is definitely way beyond the scope of this mailing list, and should be between your routing engineers, their routing engineers, and your router vendor. I suspect RIPE would never assign padding space in an allocation. Joshua -[ Joshua Goodall ]----------------------------------------------- -[ Chief Systems Architect, IP R&D, InterXion ]------------------- -[ joshuag at interxion.com ]--------------[ joshua at roughtrade.net ]- > GB-10488 p.s. shouldn't that be GB10488-RIPE? pps Edinburgh still lovely at this time of year? From skals at cybercity.dk Fri Sep 1 13:21:55 2000 From: skals at cybercity.dk (Simon Skals) Date: Fri, 01 Sep 2000 13:21:55 +0200 Subject: Question In-Reply-To: <00090112142001.00781@tabitha.nsl.net> References: Message-ID: <4.3.2.20000901131957.00e3cb50@www4.cybercity.dk> It seems Graham Burke wrote: >Hi just a quick question >We have been recently been allocated our /19 however RIPE have assigned us only >the first 700 address this I believe is pretty standard procedure. > >However our connectivity supplier will not advertise our routes unless we have >our full /19 assigned and registered with RIPE, obvioulsy as the range is too >small. > Is there any other way around this problem other than getting RIPE to >register our full /19 reserved pre-allocation, if not how do RIPE stand on >registering the full /19????? If a /19 has been allocated to you, any sensible transit provider will advertise it, too. Is the allocation's inetnum object in the RIPE DB? Cheers, -Simon From leigh at insnet.net Fri Sep 1 15:40:56 2000 From: leigh at insnet.net (Leigh Porter) Date: Fri, 01 Sep 2000 14:40:56 +0100 Subject: Question References: Message-ID: <39AFB1E8.77215CA4@insnet.net> Joshua Goodall wrote: > > On Fri, 1 Sep 2000, Graham Burke wrote: > > > Hi just a quick question > > We have been recently been allocated our /19 however RIPE have > > assigned us only the first 700 address this I believe is pretty > > standard procedure. > > > > However our connectivity supplier will not advertise our routes unless > > we have our full /19 assigned and registered with RIPE, obvioulsy as > > the range is too small. > > Graham, > > Your transit provider is almost certainly in error. Unless you are asking > them to route individual prefixes to places other than your network, it is > simply a matter of them announcing your /19 at their border. Hiya, The problem the connectivity provider has is that the fact that the whole /19 is assigned to nsl is not reflected in the RIPE database, the allocated /23 and bit of /24 are indeed there however the /19 is not. The providor is meerly trying to make sure they do not announce other peoples address space by checking the database to ensure that this /19 does indeed belong to NSL. Not that NSL are not to be trusted, far from it, but a simple error in an email and no RIPE checks can mean that a network starts announcing bits of other peoples address space :) -- Leigh Porter INS From woeber at cc.univie.ac.at Fri Sep 1 15:54:07 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Fri, 01 Sep 2000 15:54:07 MET-DST Subject: SLA's needed !!! [2: ed. amendment] Message-ID: <009EF7B5.532D12D0.1@cc.univie.ac.at> On August 31 I sent a message with the following text at the beginning: >>Subj: RE: SLA's needed !!! (Was: Re: ASN wait time) > > IMHO, it's "fairly" simple to get this problem under control: > > Assumptions: > > - the RIPE NCC is working for it's members and for the common good of > the (european) Internet (providers, and thus, indiretly users). I was putting that together in a bit of a hurry, so the wording used was quite sloppy. As AMRM correctly pointed out (thanks - appreciated!), this should have read: - the RIPE NCC is working for it's members and for the common good of the "RIPE Region" Internet (providers, and thus, indirectly users). I'd also like to grab that opportunity to add that IMHO the NCC is doing very well in that respect, and that this is not an "assumption"! Apologies if I managed to mislead anyone. Regards, Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber at CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From joshua at roughtrade.net Fri Sep 1 16:56:41 2000 From: joshua at roughtrade.net (Joshua Goodall) Date: Fri, 1 Sep 2000 16:56:41 +0200 (CEST) Subject: Question In-Reply-To: <39AFB1E8.77215CA4@insnet.net> Message-ID: On Fri, 1 Sep 2000, Leigh Porter wrote: > Hiya, > > The problem the connectivity provider has is that the fact that the > whole /19 is assigned to nsl is not reflected in the RIPE database, > the allocated /23 and bit of /24 are indeed there however the /19 is > not. mm, maybe, but on closer inspection... joshua at juice:~$ ripewhois -r 62.128.192.0/19 % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 62.128.192.0 - 62.128.223.255 netname: UK-NSL-20000626 descr: PROVIDER country: GB admin-c: CS9003-RIPE tech-c: SZ1652-RIPE status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT changed: hostmaster at ripe.net 20000626 changed: hostmaster at ripe.net 20000901 source: RIPE ... which is probably the object that Graham should beat the transit provider with. Joshua From prt at Teleglobe.net Fri Sep 1 17:20:35 2000 From: prt at Teleglobe.net (Pierre Thibaudeau) Date: Fri, 1 Sep 2000 11:20:35 -0400 (EDT) Subject: Is this normal behaviour? In-Reply-To: Message-ID: On Thu, 31 Aug 2000, Marco Davids wrote: > Date: Thu, 31 Aug 2000 16:31:27 +0200 (MET DST) > From: Marco Davids > To: lir-wg at ripe.net > Cc: db-wg at ripe.net > Subject: Is this normal behaviour? > > Hello, > > A routine check on as-macro AS-EURONET on the RIPE-database returned an > unexpected result. > > The same check on the RADB whoisd (whois.raddb.net) however, returned the > expected result together with two unexpected ones. > > Investigation learned us that someone deleted an unprotected as-macro on > the RIPE-database. It seems it is fixed now. > > But what I would like to know is to what extend the several whois > databases a synchronised, in other words; how reliable is the information > retrieved from it? And... is the as-set object supposed to be unique or > not? as-sets (and all objects) are unique _within one registry_. When a given object is registered in multiple registries, synchronization is the responsibility of whoever register those multiple instances because when they reach servers like whois.radb.net (which mirrors multiple registries) they are kept as distinct objects. When you query whois.radb.net you will see all instances of a given object (eg. AS-GLOBALCENTER that's registered in four different registries). The problem with inconsistent objects is that unlike a whois client (which returns all objects found on a given server), tools that builds BGP filters from the IRR will only consider the first instance found for an as-set; the search order beeing dependant on the whois server admin. Another aspect of synchronization is mirroring, which, under normal conditions, is never too far behind on well managed servers like whois.radb.net. (There are exceptions though [even on whois.radb.net]: some registries - like CW, ARIN, etc. - do not offer real time mirroring possibilities; they can only be mirrored from checkpoint files that are made available for ftp only once a day.) Cheers. __ Pierre Thibaudeau | e-mail: TELEGLOBE CANADA | e-page: 1000, rue de La Gauchetiere ouest | Montreal, QC H3B 4X5 | Tel: +1-514-868-7257 Canada | fax: +1-514-868-8446 > > -- > Marco Davids / SARA - Academic Computing Services Amsterdam > > Today's tip: ftp://ftp.ripe.net/rfc/rfc1925.txt > From nurani at ripe.net Fri Sep 1 17:33:58 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 01 Sep 2000 17:33:58 +0200 Subject: Ticket handling at the RIPE NCC Message-ID: <200009011533.RAA01628@x7.ripe.net> Dear all, Prior to sending a mail to the lir-wg regarding an on-going request, I would like to encourage you to check the actual status of your request. This can be done at the following URL: http://www.ripe.net/cgi-bin/rttquery The wait queue is indeed high and you may have to wait up to two weeks before an *initial* response from the hostmasters at the RIPE NCC. However, once your ticket is being processed, you normally get a reply within one working day. So if you are waiting for the reply to an on-going request for more than a couple of days, it is highly possible that the RIPE NCC has responded to your request and is waiting for additional information from you before proceeding further with the request. If you have checked the status of your request using the rttquery and you have in fact not received notification from the RIPE NCC, please do not hesitate to contact us through the mailbox, including the ticket number of your on-going request. By including the ticket number of your on-going request, you will *not* be put at the bottom of the wait queue and can expect a prompt reply. I hope this clarifies how your tickets are handled by the RIPE NCC. Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC From nurani at ripe.net Fri Sep 1 18:56:36 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 01 Sep 2000 18:56:36 +0200 Subject: Tips for IP and AS Requests! Message-ID: <200009011656.SAA02084@x7.ripe.net> Dear all, We are happy to announce From nurani at ripe.net Fri Sep 1 19:05:38 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Fri, 01 Sep 2000 19:05:38 +0200 Subject: Tips for IP and AS Requests! Message-ID: <200009011705.TAA02131@x7.ripe.net> Dear all, We are happy to announce our new "TIPS" page on the RIPE NCC website! The RIPE NCC hostmasters have put together a clear, concise and comprehensible list of tips useful to LIRs when requesting Address Space and Autonomous System Numbers from the RIPE NCC. The TIPS page can be reached from our main page and can be found at: http://www.ripe.net/ripencc/tips/tips3.html This is one of several steps we are taking in improving the documentation on our website, making vital information more comprehensible and accessible to our members. We hope this is useful to you in your communication with the RIPE NCC! Kind regards, -- Nurani Nimpuno Registration Services Manager RIPE NCC From abdullah at awalnet.net.sa Sat Sep 2 07:43:09 2000 From: abdullah at awalnet.net.sa (Abdullah Saad Al-Ashry) Date: Sat, 2 Sep 2000 08:43:09 +0300 Subject: ripe-db question In-Reply-To: <20000830142340.20828.qmail@demdwu24.mediaways.net> Message-ID: Salaam, You can get the address space allocated to Local Internet Registries from - http://www.ripe.net/ripencc/mem-services/general/allocs4.html for Pv4 Allocations - http://www.ripe.net/ripencc/mem-services/general/allocs6.html for IPv6 Allocations this list is updated daily. Every record is in the format as X-NCC-RegID, for example: sa.faisaliah (AL Faisaliah Internet Services & Technology) 19990518 212.93.192/19 ALLOCATED PA You can retrieve this file daily and make a search on it. Regards; Abdullah Saad M. Al-Ashry Al Faisaliah Internet Services and Technology Est. (AwalNet) Tel: +966-1-4600111 x 311 Fax: +966-1-4601110 -----Original Message----- From: owner-lir-wg at ripe.net [mailto:owner-lir-wg at ripe.net]On Behalf Of mediaWays Hostmaster Sent: Wed, August 30, 2000 5:24 PM To: lir-wg at ripe.net; db-wg at ripe.net Subject: ripe-db question Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf at mediaways.net From abdullah at awalnet.net.sa Sat Sep 2 09:58:45 2000 From: abdullah at awalnet.net.sa (Abdullah Saad Al-Ashry) Date: Sat, 2 Sep 2000 10:58:45 +0300 Subject: asused question Message-ID: Hi, When I use the utility "asused" ftp://ftp.ripe.net/tools/asused-3.5.tar.gz It gives me this warning: **************** Please check the following WARNINGS: 212.xx.xxx.0 - 212.xx.xxx.255 has mnt-lower xxxx attached **************** Could anybody explain this. Regards; ---------------------------------------------------------------------- Abdullah Saad M. Al-Ashry Al Faisaliah Internet Services and Technology Est. (AwalNet) Tel: +966-1-4600111 x 311 Fax: +966-1-4601110 From andrius at andrius.org Sat Sep 2 14:01:43 2000 From: andrius at andrius.org (Andrius Kasparavicius) Date: Sat, 2 Sep 2000 14:01:43 +0200 (GMT-2) Subject: ripe-db question In-Reply-To: <01C012A8.734BB140@kleopatra.m.INFRA.NET> Message-ID: On Wed, 30 Aug 2000, Christian Storch wrote: > Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. > - Perhaps that page could solve your question. hmm, look at lt.Omnitel: lt.omnitel (OMNITEL Net) 19951120 194.176.32/19 ALLOCATED PA 19971010 195.22.160/19 ALLOCATED PA 19990913 212.47.96/19 ALLOCATED PA querry ripe database for 205.244.196.0/24 or for 205.244.197.0/24 route: 205.244.197.0/24 descr: OMNITEL descr: Joint Lithuanian-USA Closed Stock Company descr: Vilnius, Lithuania descr: GSM communications and data networks origin: AS5522 mnt-by: AS5522-MNT changed: daiva at kaunas.omnitel.net 19970605 source: RIPE route: 205.244.196.0/24 descr: OMNITEL descr: Joint Lithuanian-USA Closed Stock Company descr: Vilnius, Lithuania descr: GSM communications and data networks origin: AS5522 mnt-by: AS5522-MNT changed: daiva at kaunas.omnitel.net 19970605 source: RIPE it mean's that in allocation list, is not all ip blocks allocated to LIR's. Why? Andrius From maldwyn at ripe.net Fri Sep 1 18:48:23 2000 From: maldwyn at ripe.net (Maldwyn Morris) Date: Fri, 01 Sep 2000 18:48:23 +0200 Subject: ANNOUNCEMENT: Release of stt2 Message-ID: <200009011648.SAA21409@birch.ripe.net> Hi, The RIPE NCC are pleased to announce the release of stt2. Stt2 is a tool that uses templates to produce customised standard emails. These templates may also contain Perl code to produce the email text and perform other actions. The standard usage is to produce a reply to the current message using the template specified. stt2 is a complete re-write of stt. The main changes are: * It is now a Perl 5 program, * It uses standard CPAN modules where possible * One can use modules in the templates * There is new variable type, VARMULTI * One can restrict editing to just the text part of a template The software is written in standard Perl 5 and uses several standard CPAN modules. It uses and requires MH. It was written and tested on BSD/OS 3.1, and due to OS dependencies, will probably not work on other OSes. We welcome patches for other OSes. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/stt2.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. We are keen to receive your feedback on this software - please address your comments and/or suggestions to me. Cheers, Maldwyn Morris maldwyn at ripe.net Software Manager RIPE NCC From chair at ietf.org Fri Sep 1 21:40:48 2000 From: chair at ietf.org (Fred Baker) Date: Fri, 01 Sep 2000 12:40:48 -0700 Subject: IAB/IESG Recommendations on IPv6 Address Delegation Message-ID: <4.3.2.7.2.20000901123010.0243af00@flipper.cisco.com> Folks: The RIR community asked the IETF community for advice regarding the assignment of IPv6 prefixes to service providers and edge networks, both with a view to topological address assignment and to multihomed networks. The IPv6 Directorate prepared a statement, which the IESG and IAB have reviewed and approved. This is attached. I trust that this answers the questions you asked, and serves as a basis for IPv6 deployment in the near term. If you have questions or issues concerning it, I would suggest that you address them to the IPv6 Directorate copying the IESG and IAB. We intend to publish an Informational RFC in the near future documenting the contents of this note. Fred Baker ----------------------------------------------------------------------- IAB/IESG Recommendations on IPv6 Address Allocations September 1, 2000 Introduction During a discussion between IETF and RIR experts at the Adelaide IETF, a suggestion was made that it might be appropriate to allocate /56 prefixes instead of /48 for homes and small businesses. However, subsequent analysis has revealed significant advantages in using /48 uniformly. This note is an update following further discussions at the Pittsburgh IETF. This document was developed by the IPv6 Directorate, IAB and IESG, and is a recommendation from the IAB and IESG to the RIRs. Background The technical principles that apply to address allocation seek to balance healthy conservation practices and wisdom with a certain ease of access. On the one hand, when managing the use of a potentially limited resource, one must conserve wisely to prevent exhaustion within an expected lifetime. On the other hand, the IPv6 address space is in no sense as precious a resource as the IPv4 address space, and unwarranted conservatism acts as a disincentive in a marketplace already dampened by other factors. So from a market development perspective, we would like to see it be very easy for a user or an ISP to obtain as many IPv6 addresses as they really need without a prospect of immediate renumbering or of scaling inefficiencies. The IETF makes no comment on business issues or relationships. However, in general, we observe that technical delegation policy can have strong business impacts. A strong requirement of the address delegation plan is that it not be predicated on or unduly bias business relationships or models. The IPv6 address, as currently defined, consists of 64 bits of "network number" and 64 bits of "host number". The technical reasons for this are several. The requirements for IPv6 agreed to in 1993 included a plan to be able to address approximately 2^40 networks and 2^50 hosts; the 64/64 split effectively accomplishes this. Procedures used in host address assignment, such as the router advertisement of a network's prefix to hosts [RFC 2462], which in turn place a locally unique number in the host portion, depend on this split. Examples of obvious choices of host number (IEEE Mac Address, E.164 number, E.214 IMSI, etc) suggest that no assumption should be made that bits may be stolen from that range for subnet numbering; current generation MAC layers and E.164 numbers specify up to 64 bit objects. Therefore, subnet numbers must be assumed to come from the network part. This is not to preclude routing protocols such as IS-IS level 1 (intra-area) routing, which routes individual host addresses, but says that it may not be depended upon in the world outside that zone. The IETF has also gone to a great deal of effort to minimize the impacts of network renumbering. None-the-less, renumbering of IPv6 networks is neither invisible nor completely painless. Therefore, renumbering should be considered an acceptable event, but to be avoided if reasonably avoidable. The IETF's IPNG working group has recommended that the address block given to a single edge network which may be recursively subnetted be a 48 bit prefix. This gives each such network 2^16 subnet numbers to use in routing, and a very large number of unique host numbers within each network. This is deemed to be large enough for most enterprises, and to leave plenty of room for delegation of address blocks to aggregating entities. It is not obvious, however, that all edge networks are likely to be recursively subnetted; an individual PC in a home, or a single cell in a mobile telephone network, for example, may or may not be further subnetted (depending whether they are acting as, e.g., gateways to personal, home, or vehicular networks). When a network number is delegated to a place that will not require subnetting, therefore, it might be acceptable for an ISP to give a single 64 bit prefix - perhaps shared among the dial-in connections to the same ISP router. However this decision may be taken in the knowledge that there is objectively no shortage of /48s, and the expectation that personal, home and vehicle networks will become the norm. Indeed, it is widely expected that all IPv6 subscribers, whether domestic (homes), mobile (vehicles or individuals), or enterprises of any size, will eventually possess multiple always-on hosts, at least one subnet with the potential for additional subnetting, and therefore some internal routing capability. Note that in the mobile environment, the device connecting a mobile site to the network may in fact be a third generation cellular telephone. In other words the subscriber allocation unit is not always a host; it is always potentially a site. Address Delegation Recommendations The RIR communities, with the IAB, have determined that reasonable address prefixes delegated to service providers for initial allocations should be on the order of 29 to 35 bits in length, giving individual delegations support for 2^13 (8K) to 2^19 (512K) subscriber networks. Allocations are to be given in a manner such that an initial prefix may be subsumed by subsequent larger allocations without forcing existing subscriber networks to renumber. We concur that this meets the technical requirement for manageable and scalable backbone routing while simultaneously allowing for managed growth of individual delegations. The same type of rule could be used in the allocation of addresses in edge networks; if there is doubt whether an edge network will in turn be subnetted, the edge network might be encouraged to allocate the first 64 bit prefix out of a block of 8..256, preserving room for growth of that allocation without renumbering up to a point. However, for the reasons described below, we recommend use of a fixed boundary at /48 for all subscribers except the very largest (who could receive multiple /48's), and those clearly transient or otherwise have no interest in subnetting (who could receive a /64). Note that there seems to be little benefit in not giving a /48 if future growth is anticipated. In the following, we give the arguments for a uniform use of /48 and then demonstrate that it is entirely compatible with responsible stewardship of the total IPv6 address space. The arguments for the fixed boundary are: - only by having an ISP-independent boundary can we guarantee that a change of ISP will not require a costly internal restructuring or consolidation of subnets. - to enable straightforward site renumbering, i.e., when a site renumbers from one prefix to another, the whole process, including parallel running of the two prefixes, would be greatly complicated if the prefixes had different lengths (depending of course on the size and complexity of the site). - there are various possible approaches to multihoming for IPv6 sites, including the techniques already used for IPv4 multihoming. The main open issue is finding solutions that scale massively without unduly damaging route aggregation and/or optimal route selection. Much more work remains to be done in this area, but it seems likely that several approaches will be deployed in practice, each with their own advantages and disadvantages. Some (but not all) will work better with a fixed prefix boundary. (Multihoming is discussed in more detail below.) - to allow easy growth of the subscribers' networks -- no need to keep going back to ISPs for more space (except for that relatively small number of subscribers for which a /48 is not enough). - remove the burden from the ISPs and registries of judging sites' needs for address space, unless the site requests more space than a /48, with several advantages: - ISPs no longer need to ask for details of their customers' network architecture and growth plans - ISPs and registries no longer have to judge rates of address consumption by customer type - registry operations will be made more efficient by reducing the need for evaluations and judgements - address space will no longer be a precious resource for customers, removing the major incentive for subscribers to install v6/v6 NATs, which would defeat the ability of IPv6 to restore address transparency. - to allow the site to maintain a single reverse-DNS zone covering all prefixes. - If and only if a site can use the same subnetting structure under each of its prefixes, then it can use the same zone file for the address-to-name mapping of all of them. And, using the conventions of RFC 2874, it can roll the reverse mapping data into the "forward" (name-keyed) zone. Specific advantages of the fixed boundary being at /48 include - to leave open the technical option of retro-fitting the GSE (Global, Site and End-System Designator, a.k.a "8+8") proposal for separating locators and identifiers, which assumes a fixed boundary between global and site addressing at /48. Although the GSE technique was deferred a couple of years ago, it still has strong proponents. Also, the IRTF Namespace Research Group is actively looking into topics closely related to GSE. It is still possible that GSE or a derivative of GSE will be used with IPv6 in the future. - since the site local prefix is fec0::/48, global site prefixes of /48 will allow sites to easily maintain a simple 1 to 1 mapping between the global topology and the site local topology in the SLA field. - similarly, if the 6to4 proposal is standardized, migration from a 6to4 prefix, which is /48 by construction, to a native IPv6 prefix will be simplified if the native prefix is /48. Note that none of these reasons imply an expectation that homes, vehicles, etc. will intrinsically require 16 bits of subnet space. Conservation of Address Space The question naturally arises whether giving a /48 to every subscriber represents a profligate waste of address space. Objective analysis shows that this is not the case. A /48 prefix under the Aggregatable Global Unicast Address (TLA) format prefix actually contains 45 variable bits, i.e., the number of available prefixes is 2**45 or about 35 trillion (35,184,372,088,832). If we take the limiting case of assigning one prefix per human, then the utilization of the TLA space appears to be limited to approximately 0.03% on reasonable assumptions. More precisely, - RFC 1715 defines an "H ratio" based on experience in address space assignment in various networks. Applied to a 45 bit address space, and projecting a world population of 10.7 billion by 2050 (see http://www.popin.org/pop1998/), the required assignment efficiency is log_10(1.07*10^10) / 45 = 0.22. This is less than the efficiencies of telephone numbers and DECnetIV or IPv4 addresses shown in RFC 1715, i.e., gives no grounds for concern. - We are highly confident in the validity of this analysis, based on experience with IPv4 and several other address spaces, and on extremely ambitious scaling goals for the Internet amounting to an 80 bit address space *per person*. Even so, being acutely aware of the history of under-estimating demand, we have reserved more than 85% of the address space (i.e., the bulk of the space not under the Aggregatable Global Unicast Address (TLA) format prefix). Therefore, if the analysis does one day turn out to be wrong, our successors will still have the option of imposing much more restrictive allocation policies on the remaining 85%. - For transient use by non-routing hosts (e.g., for stand-alone dial-up users who prefer transient addresses for privacy reasons), a prefix of /64 might be OK. But a subscriber who wants "static" IPv6 address space, or who has or plans to have multiple subnets, ought to be provided with a /48, for the reasons given above, even if it is a transiently provided /48. To summarize, we argue that although careful stewardship of IPv6 address space is essential, this is completely compatible with the convenience and simplicity of a uniform prefix size for IPv6 sites of any size. The numbers are such that there seems to be no objective risk of running out of space, giving an unfair amount of space to early customers, or of getting back into the over-constrained IPv4 situation where address conservation and route aggregation damage each other. Multihoming Issues In the realm of multi-homed networks, the techniques used in IPv4 can all be applied, but they have known scaling problems. Specifically, if the same prefix is advertised by multiple ISPs, the routing tables will grow as a function of the number of multihomed sites. To go beyond this for IPv6, we only have initial proposals on the table at this time, and active work is under way in the IETF IPNG working group. Until existing or new proposals become more fully developed, existing techniques known to work in IPv4 will continue to be used in IPv6. Key characteristics of an ideal multi-homing proposal include (at minimum) that it provides routing connectivity to any multi-homed network globally, conserves address space, produces high quality routes at least as well as the single-homed host case previously discussed via any of the network's providers, enables a multi-homed network to connect to multiple ISPs, does not inherently bias routing to use any proper subset of those networks, does not unduly damage route aggregation, and scales to very large numbers of multi-homed networks. One class of solution being considered amounts to permanent parallel running of two (or more) prefixes per site. In the absence of a fixed prefix boundary, such a site might be required to have multiple different internal subnet numbering strategies, (one for each prefix length) or, if it only wanted one, be forced to use the most restrictive one as defined by the longest prefix it received from any of its ISPs. In this approach, a multi-homed network would have an address block from each of its upstream providers. Each host would either have exactly one address picked from the set of upstream providers, or one address per host from each of the upstream providers. The first case is essentially a variant on RFC 2260, with known scaling limits. In the second case (multiple addresses per host), if two multi-homed networks communicate, having respectively m and n upstream providers, then the one initiating the connection will select one address pair from the n*m potential address pairs to connect from and to, and in so doing will select the providers, and therefore the applicable route, for the life of the connection. Given that each path will have a different ambient bit rate, loss rate, and delay, if neither host is in possession of any routing or metric information, the initiating host has only a 1/(m*n) probability of selecting the optimal address pair. Work on better-than-random address selection is in progress in the IETF, but is incomplete. An existence proof exists in the existing IPv4 Internet that a network whose address is distinct from and globally advertised to all upstream providers permits the routing network to select a reasonably good path within the applicable policy. Present-day routing policies are not QoS policies but reachability policies, which means that they will not necessarily select the optimal delay, bit rate, or loss rate, but the route will be the best within the metrics that are indeed in use. One may therefore conclude that this would work correctly for IPv6 networks as well, apart from scaling issues. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Fred Baker | 519 Lado Drive IETF Chair | Santa Barbara California 93111 www.ietf.org | Desk: +1-408-526-4257 | Mobile: +1-805-886-3873 | FAX: +1-413-473-2403 From storch at infra.net Sat Sep 2 15:47:13 2000 From: storch at infra.net (Christian Storch) Date: Sat, 2 Sep 2000 15:47:13 +0200 Subject: ripe-db question Message-ID: <200009021344.PAA01496@gamma2.m.infra.net> You're right! That number space wasn't registrated at RIPE - you have to look at ARIN: http://www.arin.net/cgi-bin/whois.pl?queryinput=NETBLK-SPRINT-CDF4C7 The AS of omnitel looks like the first upstream provider of Omnitel was SprintLink (USA) and the second is Telianet (Sweden). So the address space 205.244.196.0/24 seems to be registrated by SprintLink at ARIN. Later it becomes an LIR at RIPE and so on... So I think for that you would have to ask all RIR's for your purpose: RIPE, ARIN and APNIC. And you won't get always the right answer for your geographical question I think. Christian ---------- | Von: Andrius Kasparavicius | An: Christian Storch | Cc: 'mediaWays Hostmaster' ; lir-wg at ripe.net; db-wg at ripe.net | Betreff: RE: ripe-db question | Datum: Samstag, 2. September 2000 14:01 | | On Wed, 30 Aug 2000, Christian Storch wrote: | | > Take a look at http://www.ripe.net/ripencc/mem-services/general/allocs4.html. | > - Perhaps that page could solve your question. | | hmm, look at lt.Omnitel: | lt.omnitel (OMNITEL Net) | 19951120 194.176.32/19 ALLOCATED PA | 19971010 195.22.160/19 ALLOCATED PA | 19990913 212.47.96/19 ALLOCATED PA | | querry ripe database for 205.244.196.0/24 or for 205.244.197.0/24 | | route: 205.244.197.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva at kaunas.omnitel.net 19970605 | source: RIPE | | route: 205.244.196.0/24 | descr: OMNITEL | descr: Joint Lithuanian-USA Closed Stock Company | descr: Vilnius, Lithuania | descr: GSM communications and data networks | origin: AS5522 | mnt-by: AS5522-MNT | changed: daiva at kaunas.omnitel.net 19970605 | source: RIPE | | | it mean's that in allocation list, is not all ip blocks allocated to | LIR's. Why? | | Andrius From jruigrok at via-net-works.nl Sun Sep 3 13:23:16 2000 From: jruigrok at via-net-works.nl (Jeroen Ruigrok van der Werven) Date: Sun, 3 Sep 2000 13:23:16 +0200 Subject: asused question In-Reply-To: ; from abdullah@awalnet.net.sa on Sat, Sep 02, 2000 at 10:58:45AM +0300 References: Message-ID: <20000903132316.C81000@lucifer.bart.nl> -On [20000902 10:05], Abdullah Saad Al-Ashry (abdullah at awalnet.net.sa) wrote: >When I use the utility "asused" ftp://ftp.ripe.net/tools/asused-3.5.tar.gz >It gives me this warning: >**************** >Please check the following WARNINGS: >212.xx.xxx.0 - 212.xx.xxx.255 has mnt-lower xxxx attached >**************** You probably have: mnt-by: MNT-BLAH mnt-lower: MNT-BLAH which is ambiguous if memory serves me right. Just remove the mnt-lower. This is just a guess, since you are paranoia and removed the specifices of your assignment [for which I really cannot find any justification actually, the paranoia that is]. HTH, kind regards, -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Come and take a good look deep into these thuggish ruggish eyes. See the thugstas cry. And I'm askin' the good Lord "Why?" and sigh, He told me we lived to die... From herbert at hostit.be Mon Sep 4 11:07:16 2000 From: herbert at hostit.be (Herbert Baerten) Date: Mon, 4 Sep 2000 11:07:16 +0200 Subject: asused question In-Reply-To: <20000903132316.C81000@lucifer.bart.nl> Message-ID: > >Please check the following WARNINGS: > >212.xx.xxx.0 - 212.xx.xxx.255 has mnt-lower xxxx attached > > You probably have: > > mnt-by: MNT-BLAH > mnt-lower: MNT-BLAH > > which is ambiguous if memory serves me right. > > Just remove the mnt-lower. I get the same warning on an object with: mnt-by: RIPE-NCC-HM-MNT mnt-lower: AS9166-MNT Removing the mnt-lower is not an option, as we want to be in control over who adds inetnums 'inside' our allocation... I don't consider this paranoia, AFAIK this is what mnt-lower is all about? Herbert -- Herbert Baerten HostIT Network Manager HB5351 From kevin.bates at bt.com Mon Sep 4 11:23:12 2000 From: kevin.bates at bt.com (kevin.bates at bt.com) Date: Mon, 4 Sep 2000 10:23:12 +0100 Subject: asused question Message-ID: Greetings Having a "mnt-by" in an object prevents anyone not in the maintainer group from changing the data for that object (i.e. an inetnum). Having a "mnt-lower" in an object prevents anyone not in the maintainer group from changing the data below that object. So, I believe, without the "mnt-lower" in an inetnum, it is possible for anyone to add additional inetnum objects into the RIPE database, below your inetnum record, and for them to put another maintainer into the addition. You could then end up with false records within your assignment that you would be unable to remove. kevin > -----Original Message----- > From: Jeroen Ruigrok van der Werven [SMTP:jruigrok at via-net-works.nl] > Sent: 03 September 2000 12:23 > To: Abdullah Saad Al-Ashry > Cc: lir-wg at ripe.net; db-wg at ripe.net > Subject: Re: asused question > > -On [20000902 10:05], Abdullah Saad Al-Ashry (abdullah at awalnet.net.sa) > wrote: > >When I use the utility "asused" > ftp://ftp.ripe.net/tools/asused-3.5.tar.gz > >It gives me this warning: > >**************** > >Please check the following WARNINGS: > >212.xx.xxx.0 - 212.xx.xxx.255 has mnt-lower xxxx attached > >**************** > > You probably have: > > mnt-by: MNT-BLAH > mnt-lower: MNT-BLAH > > which is ambiguous if memory serves me right. > > Just remove the mnt-lower. > > This is just a guess, since you are paranoia and removed the specifices > of your assignment [for which I really cannot find any justification > actually, the paranoia that is]. > > HTH, > > kind regards, > > -- > Jeroen Ruigrok van der Werven Network- and systemadministrator > VIA Net.Works The Netherlands > BSD: Technical excellence at its best http://www.via-net-works.nl > Come and take a good look deep into these thuggish ruggish eyes. See the > thugstas cry. And I'm askin' the good Lord "Why?" and sigh, He told me we > lived to die... From feico.dillema at invenia.no Mon Sep 4 15:30:51 2000 From: feico.dillema at invenia.no (Feico Dillema) Date: Mon, 4 Sep 2000 15:30:51 +0200 Subject: Address Space Waiting Time... In-Reply-To: <4.3.2.7.2.20000831074303.00ac94c0@max.ibm.net.il>; from hank@att.net.il on Thu, Aug 31, 2000 at 07:45:42AM +0200 References: <20000830184957.G13005@dillema.net> <4.3.2.7.2.20000831074303.00ac94c0@max.ibm.net.il> Message-ID: <20000904153050.A857@dillema.net> On Thu, Aug 31, 2000 at 07:45:42AM +0200, Hank Nussbacher wrote: > At 18:49 30/08/00 +0200, Feico Dillema wrote: > >I filed a first request for address space for a new LIR about a week > >ago. Ticket number is NCC#2000085969 and it's still in the waiting > >queue. Can any of you give me a hint on what the average queuing time > >is at the moment? My boss is getting a bit nervous as it is on the > >critical path for meeting some deadlines, and I'd like to be able to > >tell him whether he can relax or should panic... > > Generally, you should leave anywhere from 2-4 months to complete the entire > process, IMHO. If you haven't, then you are toast. Thanks for your replies, and thanks to RIPE for the speedy handling of our request in the past week! We are happy to be able to panic about the many other things on the critical path for our project now ;-}. with kind regards, Feico Dillema. From stephenb at uk.uu.net Tue Sep 5 17:35:49 2000 From: stephenb at uk.uu.net (Stephen Burley) Date: Tue, 05 Sep 2000 15:35:49 +0000 Subject: May 17 Task Force Findings / Recommendations Message-ID: <39B512D5.DE9A8A9B@uk.uu.net> May 17 WG Meeting, 07/21/2000 Proposed Agenda: 1. Scope and goal of discussion 2. Description of current procedures for obtaining address space, assignment windows, approvals 3. New LIR growth 4. Assignment window 5. Response time and emergency measures 6. Usage Criteria 7. Category priorities 8. accessibility and communication 9. tools List of attendees Nurani Joao Anne Wilfred Stephen Barbara Daniel Sabine Gert 1. Scope and goals of discussion Propose changes to policies and procedures for address assignments to ultimately be submitted to LIR WG, with the clarification of best practices and tangible steps to achieving those goals. This group will not determine how RIPE NCC internally achieves those goals. 2. Current status of procedures a. Process includes sanity checks that may be delegated to LIRs b. Previously no automatic review of Assignment window, now auto reminders in place, made difficult by no flagging of good/bad tickets, no record of why assignment window was denied i.e.. The quality of the LIR requests will be flagged so a more informed decision of the AW status can be made. c. Wait queue due mostly to under staffing combined with significant increase in new LIR growth. d. Improving ripe-141 instructions (ripe-185) may cut down on common time-consuming errors. Although the form provides the hostmasters with enough detail to approve/decline a request it is very sparse on helpful comments for the engineer/customer filling in the details. 3. New LIRs a. Nurani provided information on how many new LIRs are being added, current rate is ~80/month b. Who is becoming an LIR? Should we actively discourage LIR's some how? Raise the setup fee? See 3d. c. LIRs are coming in a at a much faster rate than previously, ask RIPE to review resources consumed in supporting LIRs and whether it would be appropriate to create a specialized group for dealing with LIR applications, education, etc. d. Also, review new LIR fees to see if they cover resources consumed by the application and education process, a new LIR takes up more time and resources than does a large well established registry with experienced Hostmaster. But this creates a problem when the same country with more than one registry uses the same engineers how do you justify charging them more? and how do you track the experienced engineers, we could end up creating a market for exirienced RIPE hostmasters. 4. Assignment window a. Safety net would provide a certain measure of business performance, problem is that safety nets can be abused if not implemented properly. b. Flexible assignment window offers more security from abuse and a traceable audit. c. This becomes a problem of registration accuracy and address conservation, random audits difficult to perform. d. Consensus is that some process of flexible assignment windows will be appropriate to implement but it will have an upper limit. e. Run the db audit at the time of the assignment window increase, with all errors fixed for qualification. This would take the place of audits at each assignment approval request. This could also be part of the LIR's responsibility to provide a valid clean audit, rather than the hostmaster running it. It is also a measure of whether they are really competent and deserve a larger AW. 5. Category priorities: should different categories of request have different priorities in the queue? i.e. contact requests are not the same as IP requests but how do you decide how important each type is? a. once we reach our goal of having a reasonable wait queue, this issue becomes moot. b. if we reach a point where queue exceeds maximum point, then prioritization becomes useful. c. should be looked at in conjunction with response time measures. 6. Accessibility a. Phone help desk runs into problems of accessibility for language and cost factors b. Possible to set up email help desk as a test mode, possibly a three month trial c. Translation of ripe-142 and ripe-185 and other supporting address space documents to other languages to improve communication and education for LIRs. 7. Response time a. Flexible assignment windows when acceptable limit is exceeded. b. When a ticket is in the queue for longer than the target RTT, then certain simplification efforts would kick in. These could be with multiple levels of intervention, and could be invisible to the LIR as a separate process. c. Once a ticket hits the maximum RTT, a special response would occur, which would be marked as unique and auditable and the special response should be capped at a certain level (e.g. /22, or number of approvals per LIR, or other set criteria) d. RTT is defined as getting meaningful response from hostmaster (the initial human response) to ticket request, and should apply for each iteration of reply, not for overall ticket assignment e. The limiting criteria can be described as: Response times. 1-2 days - Normal and acceptable 3-4 days - Request simplification processes put in place. Or AW +1 applied on temp basis below /22 5+ days - Auto approval with auditable response on all requests in queue over 4 days up to /22 8. Usage Criteria /20 criteria a. When an LIR gets a /20 as an initial allocation, they may run into a utilization issue at the 80% mark (12.8 used, 3.2 available) with one customer able to eat this space up an LIR could end up with no IP's to assign till more allocated. Again this is only with a high wait queue once the queue is under control this also becomes moot. b. Proposal is that if the growth is happening in a very short amount of time, the utilization level could be set at an amount smaller than 80%, offering a buffer for growth. So if an LIR can show fast take up at less than 80% the rest of the /19 will be allocated. 9. Tools a. db audit tool for LIRs to run before submitting requests for allocations thus removing the need for Hostmasters to run exhaustive audits when the problems are caused by the LIR. In other words get your house in order before even coming back to RIPE NCC for more space. b. Improved user interface to forms such as the 141 syntax checker. 10. Feedback useful for evaluating the changes proposed are the collection of statistics regarding IP assignments, LIR growth, and other elements impacting this process. This should be done on a continuous basis with a web page resource for the community. 11. We will distribute minutes to the TF, then distribute them to the LIR WG and we will prepare a presentation for the September RIPE NCC meeting. Your Fellow RIPE Members May17TF From Stefan.Gasteiger at Gendorf.de Tue Sep 5 20:45:07 2000 From: Stefan.Gasteiger at Gendorf.de (Stefan.Gasteiger at Gendorf.de) Date: Tue, 5 Sep 2000 20:45:07 +0200 Subject: Ticket handling at the RIPE NCC Message-ID: <4185051FE012D411A98B0008C7337A2ED083D8@ATLANTIS> It would be fine if rttquery could also display *how long* the wait queue is ("...there are n requests to be served before you..."). Would that be possible? Stefan Gasteiger SG5599-RIPE I+K Betrieb (zertifiziert nach DIN EN ISO 9001) InfraServ Gendorf Tel.: +49 8679 7 5599 Fax: +49 8679 7 39 5599 Mobiltel.: +49 172 8649205 E-Mail: Stefan.Gasteiger at gendorf.de > -----Original Message----- > From: Nurani Nimpuno [mailto:nurani at ripe.net] > Sent: Friday, September 01, 2000 5:34 PM > To: lir-wg at ripe.net; Local Internet Registries in Europe > Subject: Ticket handling at the RIPE NCC > > > Dear all, > > Prior to sending a mail to the lir-wg regarding an on-going request, > I would like to encourage you to check the actual status of your > request. This can be done at the following URL: > http://www.ripe.net/cgi-bin/rttquery The wait queue is indeed high and you may have to wait up to two weeks before an *initial* response from the hostmasters at the RIPE NCC. However, once your ticket is being processed, you normally get a reply within one working day. So if you are waiting for the reply to an on-going request for more than a couple of days, it is highly possible that the RIPE NCC has responded to your request and is waiting for additional information from you before proceeding further with the request. If you have checked the status of your request using the rttquery and you have in fact not received notification from the RIPE NCC, please do not hesitate to contact us through the mailbox, including the ticket number of your on-going request. By including the ticket number of your on-going request, you will *not* be put at the bottom of the wait queue and can expect a prompt reply. I hope this clarifies how your tickets are handled by the RIPE NCC. Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC From joao at ripe.net Wed Sep 6 12:46:25 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 6 Sep 2000 12:46:25 +0200 Subject: Ticket handling at the RIPE NCC In-Reply-To: <4185051FE012D411A98B0008C7337A2ED083D8@ATLANTIS> References: <4185051FE012D411A98B0008C7337A2ED083D8@ATLANTIS> Message-ID: It is being modified to show the "age" of your ticket and the age of the oldest ticket in the queue. That should give you an estimate of expected time till the ticket is handled by a hostmaster. Joao Damas RIPE NCC At 20:45 +0200 5/9/00, Stefan.Gasteiger at Gendorf.de wrote: >It would be fine if rttquery could also display >*how long* the wait queue is ("...there are n >requests to be served before you..."). > >Would that be possible? > >Stefan Gasteiger >SG5599-RIPE >I+K Betrieb (zertifiziert nach DIN EN ISO 9001) >InfraServ Gendorf >Tel.: +49 8679 7 5599 >Fax: +49 8679 7 39 5599 >Mobiltel.: +49 172 8649205 >E-Mail: Stefan.Gasteiger at gendorf.de > > >> -----Original Message----- >> From: Nurani Nimpuno [mailto:nurani at ripe.net] >> Sent: Friday, September 01, 2000 5:34 PM >> To: lir-wg at ripe.net; Local Internet Registries in Europe >> Subject: Ticket handling at the RIPE NCC >> >> >> Dear all, >> >> Prior to sending a mail to the lir-wg regarding an on-going request, >> I would like to encourage you to check the actual status of your >> request. This can be done at the following URL: >> >http://www.ripe.net/cgi-bin/rttquery > >The wait queue is indeed high and you may have to wait up to two >weeks before an *initial* response from the hostmasters at the RIPE >NCC. > >However, once your ticket is being processed, you normally get a >reply within one working day. So if you are waiting for the reply to >an on-going request for more than a couple of days, it is highly >possible that the RIPE NCC has responded to your request and is >waiting for additional information from you before proceeding further >with the request. > >If you have checked the status of your request using the rttquery and >you have in fact not received notification from the RIPE NCC, please >do not hesitate to contact us through the >mailbox, including the ticket number of your on-going request. > >By including the ticket number of your on-going request, you will >*not* be put at the bottom of the wait queue and can expect a prompt >reply. > >I hope this clarifies how your tickets are handled by the RIPE NCC. > >Kind regards, > >Nurani Nimpuno >Registration Services Manager >RIPE NCC From joao at ripe.net Wed Sep 6 12:50:34 2000 From: joao at ripe.net (Joao Luis Silva Damas) Date: Wed, 6 Sep 2000 12:50:34 +0200 Subject: mnt-lower and asused Message-ID: Hi, there is nothing wrong with having your own mnt-lower on your allocation/assignment objects. The warning was the product of a small internal misunderstanding that wasn't much of a hassle when the tool was only for internal use, so it went unnoticed. asused public is being modified to only issue warnings when the mnt-lower has the RIPE NCC HM maintainer, not your own. You are encouraged to use mnt-lower in your own objects since that gives you better control over registrations in the address space allocated to you. The new release should be coming out very soon. Regards, Joao Damas RIPE NCC From jrau at dfn.de Wed Sep 6 15:54:51 2000 From: jrau at dfn.de (Juergen Rauschenbach) Date: Wed, 06 Sep 2000 15:54:51 +0200 Subject: mnt-lower and asused In-Reply-To: Message-ID: <3.0.5.32.20000906155451.00819c40@kapella.dfn.de> Hi Joao, At 12:50 06.09.00 +0200, Joao Luis Silva Damas wrote: >Hi, > >there is nothing wrong with having your own mnt-lower on your >allocation/assignment objects. > >The warning was the product of a small internal misunderstanding that >wasn't much of a hassle when the tool was only for internal use, so >it went unnoticed. > >asused public is being modified to only issue warnings when the >mnt-lower has the RIPE NCC HM maintainer, not your own. You are >encouraged to use mnt-lower in your own objects since that gives you >better control over registrations in the address space allocated to >you. > Ah - ok, I was wondering about the warning too, that?s clear now. Another problem on the Linux setup we use was that "make install" didn?t install @INC (delegations and other files) to the right places, so that asused is to be called from the installation directory. Is this known already or do you have any hint what might be wrong? >The new release should be coming out very soon. > >Regards, >Joao Damas >RIPE NCC > Regards, Juergen From jruigrok at via-net-works.nl Wed Sep 6 16:08:53 2000 From: jruigrok at via-net-works.nl (Jeroen Ruigrok van der Werven) Date: Wed, 6 Sep 2000 16:08:53 +0200 Subject: mnt-lower and asused In-Reply-To: <3.0.5.32.20000906155451.00819c40@kapella.dfn.de>; from jrau@dfn.de on Wed, Sep 06, 2000 at 03:54:51PM +0200 References: <3.0.5.32.20000906155451.00819c40@kapella.dfn.de> Message-ID: <20000906160852.L17616@lucifer.bart.nl> -On [20000906 15:55], Juergen Rauschenbach (jrau at dfn.de) wrote: [Installing delegations and other files] >Is this known already or do you have any hint what might be wrong? Known and fixed, as well as some other small bugs. -- Jeroen Ruigrok van der Werven Network- and systemadministrator VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl Necessity has no law... From dgreenfi at cmp.com Thu Sep 7 14:40:24 2000 From: dgreenfi at cmp.com (dgreenfi at cmp.com) Date: Thu, 7 Sep 2000 08:40:24 -0400 Subject: ISP Survey in Network Magazine Message-ID: <85256953.0045A199.00@NotesSMTP-01.cmp.com> I thought this might be of interest to some..... Network Magazine is planning a survey of European ISPs for its November issue. If you work for an ISP who sells to business users, consider taking 10 minutes to fill out the survey below. Why spend the time ? Simple. It's about eyeballs, as in potential customer eyeballs. Network Magazine is the only global monthly focusing on the development of large scale corporate networks. The network managers who read Net Mag are heavily involved with selecting and purchasing the IP services their companies will use. Although most are located out region, many are looking at buy services within Europe. Participating in this article is an easy way to get valuable face time (or print time as it were) with these key decision makers who normally may not be exposed to the local press. Need another reason? How about this. The first three folk who get me a survey get taken out for dinner at Interop Paris (November 6-8). Ahhh, I can smell that food now. Delivery for the feature survey is by Monday at the latest. There's a bit more time on the ISP Index. You can deliver that one by end of next week. The food deal only applies to the feature. All the best, David Greenfield International Technology Editor QUESTIONS General 1. Company Name: 2. URL: 3. If you are owned or affiliated with any organizations that might be of interest to our readers, please provide those details here. 4. Who do you see as your major competition 5. Contact name (not for publication) 6. Contact phone number and email addresss (not for publication) Geographic Coverage: 1. Please list the countries/regions where you provide Internet access. Pricing for Access Services Please provide the monthly and installation charges for the following service and itemize the amounts below. Prices should include all fees except for line charges. If line charges must be cited then please use a 5 kilometer access circuit. 1. E1 2. 256 Kbits/s 3. ISDN 4. DSL (specify speeds) 5. What are the major components driving the cost of the Internet connection (not including the access circuit)? Services Offered Please indicate the services that you provide. Check all that apply a. Dialup b. Dialup with roaming c. Internet Access (fixed line) d. Content Hosting (dedicated servers) e. Content Hosting (shared servers) f. Intranet (design; host) g. Extanet (design; host) h. E-Commerce (design; host) i. Other (specify) Service Level Agreements (SLAs) If you provide any SLAs please describe them and the penalties if they aren't met. Infrastructure 1. Who are your upstream providers for connectivity to the US? 2. Where (NAPs or countries) do you connect with them? 3. In which NAPs do you have a physical presence? --------------------------------------------------------------------------------------------------------- NETWORK MAGAZINE Incorporating Data Communication Magazine International Office #2 Chai Taib, Entrance A, Suite 6 Jerusalem, 95405, Israel v: +972-2-651-9742 e: dgreenfi at cmp.com http://www.cmp.com From herbert at hostit.be Fri Sep 8 09:56:16 2000 From: herbert at hostit.be (Herbert Baerten) Date: Fri, 8 Sep 2000 09:56:16 +0200 Subject: Changing inetnum objects In-Reply-To: Message-ID: Question: can one company foo.com request its LIR to change the company's inetnum (netname, description, tech-c) so it appears to belong to another company bar.com? If yes: who should this request come from (the original requester? management?)? If no: what if foo.com is somehow related to bar.com (e.g. foo.com is a parent or daughter of bar.com)? Suppose bar.com has taken over the internet activities from foo.com? Is there a document describing procedure to follow in such cases? tia Herbert -- HB5351 Herbert Baerten Network Manager @ HostIT Benelux From kevin.bates at bt.com Fri Sep 8 10:16:21 2000 From: kevin.bates at bt.com (kevin.bates at bt.com) Date: Fri, 8 Sep 2000 09:16:21 +0100 Subject: Changing inetnum objects Message-ID: Hi About a year ago we (an enterprise registry) had a similar issue with a number of assignments. Following discussion with the hostmasters. We used the RIPE141.txt process as the "conditions" of the original assignment had or seemed to have changed and thus virtually audited the address space usage of the gaining and loosing party. For what it is worth we ensured both parties agreed. Also if I remember correctly when the inetnum and/or the netname was changed this had an effect on the rvse delegation assignment and so that had to be "re-agreed" with the hostmasters. kevin > -----Original Message----- > From: Herbert Baerten [SMTP:herbert at hostit.be] > Sent: 08 September 2000 08:56 > To: lir-wg > Subject: Changing inetnum objects > > > Question: > > can one company foo.com request its LIR to change the company's inetnum > (netname, description, tech-c) so it appears to belong to another company > bar.com? > If yes: who should this request come from (the original requester? > management?)? > If no: what if foo.com is somehow related to bar.com (e.g. foo.com is a > parent or daughter of bar.com)? Suppose bar.com has taken over the > internet > activities from foo.com? > > Is there a document describing procedure to follow in such cases? > > tia > Herbert > > -- > HB5351 > Herbert Baerten > Network Manager @ HostIT Benelux From beri at EU.net Fri Sep 8 10:33:29 2000 From: beri at EU.net (Berislav Todorovic) Date: Fri, 8 Sep 2000 10:33:29 +0200 (CEST) Subject: Changing inetnum objects In-Reply-To: Message-ID: On Fri, 8 Sep 2000, Herbert Baerten wrote: >> can one company foo.com request its LIR to change the company's inetnum >> (netname, description, tech-c) so it appears to belong to another company >> bar.com? RIPE NCC keeps their own internal records on allocated/assigned address space. So, although you may modify anything you like in the RIPE Database, you'll get into conflicts with their internal records and that will probably trigger an auditing action from hostmasters. Not sure about "descr:" and "tech-c:" attributes, but "netname:" change will make inconsistency with internal NCC data for sure. Remember that notice when you get an assignment from NCC (if you want to combine more inetnums into one object, inform NCC ...). Finally, everything depends on your assignment window: if the inetnum covers address space smaller or equal to your assignment window - it's always better to delete the old object and create a new one for the same address range, for another customer and it's higly possible your action won't be audited, since that's a regular action. However, if the assignemnt exceeds your assignment window, it's better that you follow strict procedures: prepare the ripe-141 form for the new customer, get the approval, delete the old object, create a new object. Regards, Beri --------- Berislav Todorovic, Network Engineer --------- ------- KPNQwest N.V. - IP NOC (formerly EUnet NOC) ------- ---- Wilhelmina van Pruisenweg 78, 2595 AN Den Haag, NL ---- --- Phone: +31-70-379-3990; Mobile: +31-651-333-641 --- -- Email: beri at kpnqwest.net <=> beri at EU.net -- --- _ _ ____ _ .--. ____ ____ __/_ --- ----- /__/ /___/ /\ / / / | / /___/ /___ / ------ ------ _/ \_ / _/ \/ (__.\ |/\/ /___ ____/ (__. ----- From ncc at ripe.net Fri Sep 8 13:26:56 2000 From: ncc at ripe.net (RIPE NCC Staff) Date: Fri, 08 Sep 2000 13:26:56 +0200 Subject: New "helpdesk" mailbox for members! Message-ID: <200009081126.NAA25373@birch.ripe.net> Dear all, We are happy to inform you of a newly created mailbox within the RIPE NCC! The following mailbox is available for all RIPE NCC members to use: To accommodate some wishes raised within the RIPE NCC membership, this mailbox has been set up to serve as a form of "helpdesk" within the Registration Services, available to RIPE NCC members only. The purpose of the mailbox is offer assistance and help to our members, further facilitating the process of requesting IP Address Space from the RIPE NCC and communicating useful information. The mailbox is responded to by experienced RIPE NCC hostmasters and will be given priority over more general questions to ensure a fast and accurate answer to your queries. As a member you can use this mailbox for general policy questions as well as very specific questions related to a particular on-going request. PLEASE NOTE: As it is restricted for members only, it is important to include the Reg-Id of your organisation in all mails sent to . (The Reg-Id can be included in either the subject line or the body of the message.) Any mails that do not include a valid Reg-Id will be bounced to allow the hostmasters to concentrate on member questions, ensuring a fast response time for . We hope that you find this mailbox useful and we look forward to any feedback you may have! Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC From maldwyn at ripe.net Fri Sep 8 13:54:06 2000 From: maldwyn at ripe.net (Maldwyn Morris) Date: Fri, 08 Sep 2000 13:54:06 +0200 Subject: ANNOUNCEMENT: Third Public Beta Release of Asused In-Reply-To: Your message of Tue, 29 Aug 2000 16:37:07 +0200. <200008291437.QAA05501@birch.ripe.net> References: <200008291437.QAA05501@birch.ripe.net> Message-ID: <200009081154.NAA02296@birch.ripe.net> Hi, The RIPE NCC are pleased to announce the release of a third public beta version of Asused - this is Version 3.51. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.51.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. The changes since Version 3.5 are: * Produce a warning if an assignment overlaps allocation. * Fixed behaviour with RIPE* mnt-by and mnt-lower. * Report all Asused object warnings. * Fixed installation procedure to copy 'iso3166-codes' and 'delegations' files with other libraries to make them available with system-wide installation. * ReadConf() in a public version exitted after first guess without checking other locations. * Fixed command line argument parsing: ranges, prefixes and regids now accepted. * Program name in help now derived from $0. * Usage slightly reworded. Thanks to the following people for bug reports and suggestions: Carsten Schiefner Mark Guz :-) Stephan Mankopf Jeroen Ruigrok van der Werven Abdullah Saad M. Al-Ashry Herbert Baerten Kevin Bates Juergen Rauschenbach The original author of Asused was Daniel Karrenberg, it was worked on by Roderik Muit and Antony Antony rewrote it. The current version has been extended and fixed by Timur Bakeyev. We are keen to receive your further feedback on this software - please address your comments and/or suggestions to me. Cheers, Maldwyn Morris maldwyn at ripe.net Software Manager RIPE NCC From ncc at ripe.net Fri Sep 8 17:37:30 2000 From: ncc at ripe.net (RIPE NCC Staff) Date: Fri, 08 Sep 2000 17:37:30 +0200 Subject: Frequently Asked Questions at the RIPE NCC! Message-ID: <200009081537.RAA27692@birch.ripe.net> Dear all, We would like to draw your attention to the extended "Frequently Asked Questions" section now available on the RIPE NCC website! This FAQ can be found at the following URL: http://www.ripe.net/ripencc/faq/index.html The purpose of this FAQ is to make information about the RIPE NCC activities and services available in a clear and comprehensible manner. The FAQ is divided into the following five sections: General FAQs New LIR FAQ Registration Services FAQ Database FAQ Reverse Delegation FAQ The FAQ has been further built out with more specific questions, pointers to applicable RIPE documents and links to relevant sections. We have also added the possibility of, through the website, sending in a question that you can not find the answer to in the current FAQ. As a member you should be able to find answers to your specific questions, but we have also aimed to answer the more general questions we frequently receive from end-users, press, LIRs and members of the Internet community as a whole. We hope that this FAQ will aid you in finding the exact piece information that you are looking for on the RIPE NCC website and clarify some of the issues that concern you. Finally, with this FAQ, we also hope to relieve some of the increasingly high workload we are experiencing at the RIPE NCC. With this membership growth, higher demand is placed on resources to educate and support new LIRs. By making this information more easily accessible, the RIPE NCC aims to ensure this support, using the resources in the organisation efficiently, without compromising on the efforts invested in the Allocation of Internet Resources to the RIPE NCC membership. Kind regards, Nurani Nimpuno Registration Services Manager RIPE NCC From ncc at ripe.net Fri Sep 8 17:39:28 2000 From: ncc at ripe.net (RIPE NCC Staff) Date: Fri, 08 Sep 2000 17:39:28 +0200 Subject: RIPE NCC Tools for Members Page Message-ID: <200009081539.RAA27916@birch.ripe.net> Dear Colleagues, The RIPE NCC is pleased to inform you that there is a new web page which lists the tools that have been produced by the RIPE NCC for its members' use. These tools are designed to aid members in their interactions with the RIPE NCC Hostmasters. The tools page is available at: http://www.ripe.net/ripencc/mem-services/tools/tools.html Regards, Maldwyn Morris Software Manager RIPE NCC From hph at online.no Sun Sep 10 21:11:36 2000 From: hph at online.no (Hans Petter Holen) Date: Sun, 10 Sep 2000 21:11:36 +0200 Subject: Changing inetnum objects References: Message-ID: <000501c01b5a$f0fea240$1000000a@hph> ----- Original Message ----- From: "Berislav Todorovic" To: "Herbert Baerten" Cc: Sent: Friday, September 08, 2000 10:33 AM Subject: Re: Changing inetnum objects > On Fri, 8 Sep 2000, Herbert Baerten wrote: > > >> can one company foo.com request its LIR to change the company's inetnum > >> (netname, description, tech-c) so it appears to belong to another company > >> bar.com? > > RIPE NCC keeps their own internal records on allocated/assigned address > space. So, although you may modify anything you like in the RIPE > Database, you'll get into conflicts with their internal records and > that will probably trigger an auditing action from hostmasters. Is this correct ? I assume RIPE NCC keep internal records for allocations to LIRs but I can't really see how they could practically do this for assignments from LIRs to their customers ? I see a lot of perfectly good reasons for a LIR to do such changes (without any particular need for consulting the RIPE NCC): - the company has changed its name (i.e. same legal entity, new name) - the company has been merged with another legal entity. (i.e. new legal entity) - the company splits of its internet operations to a separate legal entity and so on... As many if not all of these scenarios are likely change the initial criteria for the assignment there is likely to be a need for the LIR to review the assignment as if the company requested new or additional address space. Whether or not consultation with the RIPE NCC is needed or not would depend on whether the assignment falls within the LIRs current assignment window or not. When that is said, it probably wont hurt to run the case trough the RIPE NCC for a second opinion if you are in doubt. But it is likely to pay off to have done the above mentioned review of the possibly changed assignment criteria before doing so. -hph From david at iprg.nokia.com Fri Sep 8 22:19:46 2000 From: david at iprg.nokia.com (David Kessens) Date: Fri, 8 Sep 2000 13:19:46 -0700 Subject: agenda for joint ipv6/lir-wg session Message-ID: <20000908131946.B11456@iprg.nokia.com> Please see below for the agenda for the joint session of the ipv6 wg and lir wg on ipv6 allocation policies. Thanks, David K. ---- A. Administrative stuff - appointment of scribe - agenda bashing B. Overview of open issues and changes in the new version of the ipv6 allocation policies document (Joao Luis Silva Damas, RIPE NCC) C. Overview of IAB/IESG Recommendations on IPv6 Address Delegation (Bob Hinden) D. Panel discussion with Bob Hinden/Steve Deering/Joao. (and other people that we will approach during the meeting). Z. AOB --- From nurani at ripe.net Mon Sep 11 11:41:47 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Mon, 11 Sep 2000 11:41:47 +0200 Subject: Changing inetnum objects In-Reply-To: Your message of Sun, 10 Sep 2000 21:11:36 +0200. <000501c01b5a$f0fea240$1000000a@hph> References: <000501c01b5a$f0fea240$1000000a@hph> Message-ID: <200009110941.LAA19003@x7.ripe.net> Dear all, Hans-Petter has already done a good job clarifying the question below, so I will simply add my additional comments from the RIPE NCC. "Hans Petter Holen" writes: * * ----- Original Message ----- * From: "Berislav Todorovic" * To: "Herbert Baerten" * Cc: * Sent: Friday, September 08, 2000 10:33 AM * Subject: Re: Changing inetnum objects * * * > On Fri, 8 Sep 2000, Herbert Baerten wrote: * > * > >> can one company foo.com request its LIR to change the company's inetnum * > >> (netname, description, tech-c) so it appears to belong to another * company * > >> bar.com? * > * > RIPE NCC keeps their own internal records on allocated/assigned address * > space. So, although you may modify anything you like in the RIPE * > Database, you'll get into conflicts with their internal records and * > that will probably trigger an auditing action from hostmasters. It is correct that if the netname attribute in the inetnum object in the RIPE database changes or if you intend to combine multiple assignments into one object in the future, you are required to inform the RIPE NCC. All LIRs are informed of this as they receive their approval for an assignment from the RIPE NCC. However, any contact details, telephone numbers, names etc can be changed without having to inform the RIPE NCC. As it is a public database, the responsibility of the information entered in the database, lies with whoever has entered the the data in the database. (As Hans-Petter points out, it would be practically impossible for the RIPE NCC to keep track of all changes made to all inetnum objects in the database.) * Is this correct ? * I assume RIPE NCC keep internal records for allocations to LIRs but I can't * really see how they could practically do this for assignments from LIRs to * their customers ? * * I see a lot of perfectly good reasons for a LIR to do such changes * (without any particular need for consulting the RIPE NCC): * - the company has changed its name (i.e. same legal entity, new name) * - the company has been merged with another legal entity. (i.e. new legal * entity) * - the company splits of its internet operations to a separate legal entity * and so on... * * As many if not all of these scenarios are likely change the initial * criteria for the assignment there is likely to be a need for the LIR to * review the assignment as if the company requested new or additional address * space. Indeed. To quote the RIPE document "European Internet Registry Policies and Procedures": "Assignments of any kind of address space are valid as long as the original criteria on which the assignment was based are still valid. If an assignment is made for a specific purpose and the purpose no longer exists, then the assignment is no longer valid. If an assignment is based on information that turns out to be invalid so is the assignment." (http://www.ripe.net/ripe/docs/ripe-185.html#toc17) In other words, the *approved netname* and *size of the assignment* cannot be changed without contacting the RIPE NCC as this would entail a change of the original criteria of the assignment. * Whether or not consultation with the RIPE NCC is * needed or not would depend on whether the assignment falls within the LIRs * current assignment window or not. This is also correct. If the assignments fall within your Assignment Window you are not required to inform the RIPE NCC of the changes (as these assignments do not have to be approved by the RIPE NCC, but fall within the responsibility of the LIR). (It is of course important to make sure your local records are up to date, should you be required to provide this information in the future to the RIPE NCC.) For you who are not familiar with the term "Assignment Window" I would recommend you to read the section 3.7 in "European Internet Registry Policies and Procedures": http://www.ripe.net/ripe/docs/ripe-185.html#toc39 * When that is said, it probably wont hurt to run the case trough the RIPE NCC * for a second opinion if you are in doubt. But it is likely to pay off to * have done the above mentioned review of the possibly changed assignment * criteria before doing so. * * -hph Hope this clarified the issue further. Best regards, -- Nurani Nimpuno Registration Services Manager RIPE NCC From rh at tjantik.dk Mon Sep 11 16:36:42 2000 From: rh at tjantik.dk (Rasmus Helmich) Date: Mon, 11 Sep 2000 16:36:42 +0200 Subject: Changing inetnum objects References: <000501c01b5a$f0fea240$1000000a@hph> <200009110941.LAA19003@x7.ripe.net> Message-ID: <002801c01bfd$b44572e0$6600000a@tjantik.dk> Dear All Is the information on a inetnum object name to be mailed to hostmaster at ripe.net ? Best Regards Rasmus Helmich Tjantik A/S ----- Original Message ----- From: "Nurani Nimpuno" To: "Hans Petter Holen" Cc: Sent: Monday, September 11, 2000 11:41 AM Subject: Re: Changing inetnum objects Dear all, Hans-Petter has already done a good job clarifying the question below, so I will simply add my additional comments from the RIPE NCC. "Hans Petter Holen" writes: * * ----- Original Message ----- * From: "Berislav Todorovic" * To: "Herbert Baerten" * Cc: * Sent: Friday, September 08, 2000 10:33 AM * Subject: Re: Changing inetnum objects * * * > On Fri, 8 Sep 2000, Herbert Baerten wrote: * > * > >> can one company foo.com request its LIR to change the company's inetnum * > >> (netname, description, tech-c) so it appears to belong to another * company * > >> bar.com? * > * > RIPE NCC keeps their own internal records on allocated/assigned address * > space. So, although you may modify anything you like in the RIPE * > Database, you'll get into conflicts with their internal records and * > that will probably trigger an auditing action from hostmasters. It is correct that if the netname attribute in the inetnum object in the RIPE database changes or if you intend to combine multiple assignments into one object in the future, you are required to inform the RIPE NCC. All LIRs are informed of this as they receive their approval for an assignment from the RIPE NCC. However, any contact details, telephone numbers, names etc can be changed without having to inform the RIPE NCC. As it is a public database, the responsibility of the information entered in the database, lies with whoever has entered the the data in the database. (As Hans-Petter points out, it would be practically impossible for the RIPE NCC to keep track of all changes made to all inetnum objects in the database.) * Is this correct ? * I assume RIPE NCC keep internal records for allocations to LIRs but I can't * really see how they could practically do this for assignments from LIRs to * their customers ? * * I see a lot of perfectly good reasons for a LIR to do such changes * (without any particular need for consulting the RIPE NCC): * - the company has changed its name (i.e. same legal entity, new name) * - the company has been merged with another legal entity. (i.e. new legal * entity) * - the company splits of its internet operations to a separate legal entity * and so on... * * As many if not all of these scenarios are likely change the initial * criteria for the assignment there is likely to be a need for the LIR to * review the assignment as if the company requested new or additional address * space. Indeed. To quote the RIPE document "European Internet Registry Policies and Procedures": "Assignments of any kind of address space are valid as long as the original criteria on which the assignment was based are still valid. If an assignment is made for a specific purpose and the purpose no longer exists, then the assignment is no longer valid. If an assignment is based on information that turns out to be invalid so is the assignment." (http://www.ripe.net/ripe/docs/ripe-185.html#toc17) In other words, the *approved netname* and *size of the assignment* cannot be changed without contacting the RIPE NCC as this would entail a change of the original criteria of the assignment. * Whether or not consultation with the RIPE NCC is * needed or not would depend on whether the assignment falls within the LIRs * current assignment window or not. This is also correct. If the assignments fall within your Assignment Window you are not required to inform the RIPE NCC of the changes (as these assignments do not have to be approved by the RIPE NCC, but fall within the responsibility of the LIR). (It is of course important to make sure your local records are up to date, should you be required to provide this information in the future to the RIPE NCC.) For you who are not familiar with the term "Assignment Window" I would recommend you to read the section 3.7 in "European Internet Registry Policies and Procedures": http://www.ripe.net/ripe/docs/ripe-185.html#toc39 * When that is said, it probably wont hurt to run the case trough the RIPE NCC * for a second opinion if you are in doubt. But it is likely to pay off to * have done the above mentioned review of the possibly changed assignment * criteria before doing so. * * -hph Hope this clarified the issue further. Best regards, -- Nurani Nimpuno Registration Services Manager RIPE NCC From Rimas.Janusauskas at sc.vu.lt Mon Sep 11 16:56:31 2000 From: Rimas.Janusauskas at sc.vu.lt (Rimas Janusauskas) Date: Mon, 11 Sep 2000 17:56:31 +0300 (EET DST) Subject: Changing inetnum objects In-Reply-To: <200009110941.LAA19003@x7.ripe.net> Message-ID: Dear all, HPH do not mentioned one more important reason to change netname: you suddenly find your netname is used by somebody else - it's a lot of examples in RIPE database (NCC is among them :). inetnum could hardly be used as lookup key for search, because you'll get unpredicatable result and must read description and contact information to detect, is it the same network in different countries or same name is used by not related companies. IMHO, ticket # could substitute inetnum without any pain: you should contact RIPE NCC if ticket starts with NCC# and RIPE NCC will contact you if total address space with your own ticket is over AW. just my 0.02$ With best regards, Rimas Janusauskas, Vilnius University Hostmaster ______________________________________________________________________ P.O.Box 543 e-mail: rimas.janusauskas at sc.vu.lt LT-2024 Vilnius Lithuania fax/phone: +370 2 687188 ______________________________________________________________________ On Mon, 11 Sep 2000, Nurani Nimpuno wrote: > Dear all, > > Hans-Petter has already done a good job clarifying the question > below, so I will simply add my additional comments from the RIPE NCC. > > "Hans Petter Holen" writes: > * > * ----- Original Message ----- > * From: "Berislav Todorovic" > * To: "Herbert Baerten" > * Cc: > * Sent: Friday, September 08, 2000 10:33 AM > * Subject: Re: Changing inetnum objects > * > * > * > On Fri, 8 Sep 2000, Herbert Baerten wrote: > * > > * > >> can one company foo.com request its LIR to change the > company's inetnum > * > >> (netname, description, tech-c) so it appears to belong to > another > * company > * > >> bar.com? > * > > * > RIPE NCC keeps their own internal records on allocated/assigned > address > * > space. So, although you may modify anything you like in the RIPE > * > Database, you'll get into conflicts with their internal records > and > * > that will probably trigger an auditing action from hostmasters. > > It is correct that if the netname attribute in the inetnum object in > the RIPE database changes or if you intend to combine multiple > assignments into one object in the future, you are required to inform > the RIPE NCC. All LIRs are informed of this as they receive their > approval for an assignment from the RIPE NCC. > > However, any contact details, telephone numbers, names etc can be > changed without having to inform the RIPE NCC. As it is a public > database, the responsibility of the information entered in the > database, lies with whoever has entered the the data in the database. > > (As Hans-Petter points out, it would be practically impossible for > the RIPE NCC to keep track of all changes made to all inetnum objects > in the database.) > > * Is this correct ? > * I assume RIPE NCC keep internal records for allocations to LIRs > but I can't > * really see how they could practically do this for assignments from > LIRs to > * their customers ? > * > * I see a lot of perfectly good reasons for a LIR to do such changes > * (without any particular need for consulting the RIPE NCC): > * - the company has changed its name (i.e. same legal entity, new > name) > * - the company has been merged with another legal entity. (i.e. new > legal > * entity) > * - the company splits of its internet operations to a separate > legal entity > * and so on... > * > * As many if not all of these scenarios are likely change the initial > * criteria for the assignment there is likely to be a need for the > LIR to > * review the assignment as if the company requested new or > additional address > * space. > > Indeed. To quote the RIPE document "European Internet Registry > Policies and Procedures": > > "Assignments of any kind of address space are valid as long as the > original criteria on which the assignment was based are still valid. > If an assignment is made for a specific purpose and the purpose no > longer exists, then the assignment is no longer valid. If an > assignment is based on information that turns out to be invalid so is > the assignment." > > (http://www.ripe.net/ripe/docs/ripe-185.html#toc17) > > In other words, the *approved netname* and *size of the assignment* > cannot be changed without contacting the RIPE NCC as this would > entail a change of the original criteria of the assignment. > > > * Whether or not consultation with the RIPE NCC is > * needed or not would depend on whether the assignment falls within > the LIRs > * current assignment window or not. > > This is also correct. > If the assignments fall within your Assignment Window you are not > required to inform the RIPE NCC of the changes (as these assignments > do not have to be approved by the RIPE NCC, but fall within the > responsibility of the LIR). > > (It is of course important to make sure your local records are up to > date, should you be required to provide this information in the > future to the RIPE NCC.) > > For you who are not familiar with the term "Assignment Window" I > would recommend you to read the section 3.7 in "European Internet > Registry Policies and Procedures": > > http://www.ripe.net/ripe/docs/ripe-185.html#toc39 > > > * When that is said, it probably wont hurt to run the case trough > the RIPE NCC > * for a second opinion if you are in doubt. But it is likely to pay > off to > * have done the above mentioned review of the possibly changed > assignment > * criteria before doing so. > * > * -hph > > Hope this clarified the issue further. > > Best regards, > > -- > Nurani Nimpuno > Registration Services Manager > RIPE NCC > > From eamonn at ripe.net Mon Sep 11 16:49:17 2000 From: eamonn at ripe.net (Eamonn McGuinness) Date: Mon, 11 Sep 2000 16:49:17 +0200 Subject: Changing inetnum objects In-Reply-To: Your message of Mon, 11 Sep 2000 16:36:42 +0200. <002801c01bfd$b44572e0$6600000a@tjantik.dk> References: <002801c01bfd$b44572e0$6600000a@tjantik.dk> Message-ID: <200009111449.QAA13774@birch.ripe.net> Hi Rasmus, You send the updated object to . In a separate e-mail to , you can inform us of the change. Remember to add the relevant ticket number of the original request so that we will know which network you are referring to (if you don't it'll be put at the bottom of the wait queue). As Nurani pointed out before, if the assignment was within your AW, there is no need to inform us of the change to the object. Cheers, Eamonn McGuinness RIPE NCC Hostmaster "RIPE NCC - One of the largest Regional Registries in the World" In message <002801c01bfd$b44572e0$6600000a at tjantik.dk>you write: >Dear All > >Is the information on a inetnum object name to be mailed to >hostmaster at ripe.net ? > >Best Regards >Rasmus Helmich >Tjantik A/S > >----- Original Message ----- >From: "Nurani Nimpuno" >To: "Hans Petter Holen" >Cc: >Sent: Monday, September 11, 2000 11:41 AM >Subject: Re: Changing inetnum objects > > >Dear all, > >Hans-Petter has already done a good job clarifying the question >below, so I will simply add my additional comments from the RIPE NCC. > > "Hans Petter Holen" writes: > * > * ----- Original Message ----- > * From: "Berislav Todorovic" > * To: "Herbert Baerten" > * Cc: > * Sent: Friday, September 08, 2000 10:33 AM > * Subject: Re: Changing inetnum objects > * > * > * > On Fri, 8 Sep 2000, Herbert Baerten wrote: > * > > * > >> can one company foo.com request its LIR to change the >company's inetnum > * > >> (netname, description, tech-c) so it appears to belong to >another > * company > * > >> bar.com? > * > > * > RIPE NCC keeps their own internal records on allocated/assigned >address > * > space. So, although you may modify anything you like in the RIPE > * > Database, you'll get into conflicts with their internal records >and > * > that will probably trigger an auditing action from hostmasters. > >It is correct that if the netname attribute in the inetnum object in >the RIPE database changes or if you intend to combine multiple >assignments into one object in the future, you are required to inform >the RIPE NCC. All LIRs are informed of this as they receive their >approval for an assignment from the RIPE NCC. > >However, any contact details, telephone numbers, names etc can be >changed without having to inform the RIPE NCC. As it is a public >database, the responsibility of the information entered in the >database, lies with whoever has entered the the data in the database. > >(As Hans-Petter points out, it would be practically impossible for >the RIPE NCC to keep track of all changes made to all inetnum objects >in the database.) > * Is this correct ? > * I assume RIPE NCC keep internal records for allocations to LIRs >but I can't > * really see how they could practically do this for assignments from >LIRs to > * their customers ? > * > * I see a lot of perfectly good reasons for a LIR to do such changes > * (without any particular need for consulting the RIPE NCC): > * - the company has changed its name (i.e. same legal entity, new >name) > * - the company has been merged with another legal entity. (i.e. new >legal > * entity) > * - the company splits of its internet operations to a separate >legal entity > * and so on... > * > * As many if not all of these scenarios are likely change the initial > * criteria for the assignment there is likely to be a need for the >LIR to > * review the assignment as if the company requested new or >additional address > * space. > >Indeed. To quote the RIPE document "European Internet Registry >Policies and Procedures": > >"Assignments of any kind of address space are valid as long as the >original criteria on which the assignment was based are still valid. >If an assignment is made for a specific purpose and the purpose no >longer exists, then the assignment is no longer valid. If an >assignment is based on information that turns out to be invalid so is >the assignment." > >(http://www.ripe.net/ripe/docs/ripe-185.html#toc17) > >In other words, the *approved netname* and *size of the assignment* >cannot be changed without contacting the RIPE NCC as this would >entail a change of the original criteria of the assignment. > > > * Whether or not consultation with the RIPE NCC is > * needed or not would depend on whether the assignment falls within >the LIRs > * current assignment window or not. > >This is also correct. >If the assignments fall within your Assignment Window you are not >required to inform the RIPE NCC of the changes (as these assignments >do not have to be approved by the RIPE NCC, but fall within the >responsibility of the LIR). > >(It is of course important to make sure your local records are up to >date, should you be required to provide this information in the >future to the RIPE NCC.) > >For you who are not familiar with the term "Assignment Window" I >would recommend you to read the section 3.7 in "European Internet >Registry Policies and Procedures": > >http://www.ripe.net/ripe/docs/ripe-185.html#toc39 > > > * When that is said, it probably wont hurt to run the case trough >the RIPE NCC > * for a second opinion if you are in doubt. But it is likely to pay >off to > * have done the above mentioned review of the possibly changed >assignment > * criteria before doing so. > * > * -hph > >Hope this clarified the issue further. > >Best regards, > >-- >Nurani Nimpuno >Registration Services Manager >RIPE NCC > > > > > > > > > > > From nurani at ripe.net Tue Sep 12 09:50:13 2000 From: nurani at ripe.net (Nurani Nimpuno) Date: Tue, 12 Sep 2000 09:50:13 +0200 Subject: RIPE meeting - wait queue Message-ID: <200009120750.JAA23648@x7.ripe.net> Dear all, As you all are aware of, the RIPE meeting is taking place this week in Amsterdam. As the RIPE NCC hostmasters are heavily with the meeting, also using it as an opportunity to meet up with members, you might notice a slight increase in the wait queue for the coming two weeks. We are currently working very hard on reducing the number of requests in the wait queue and will use the resources as efficiently as possible during the meeting in order to minimise any effect on the wait queue. Thank you for your understanding. -- Nurani Nimpuno Registration Services Manager RIPE NCC From turchany at sunserv.kfki.hu Tue Sep 12 10:27:22 2000 From: turchany at sunserv.kfki.hu (Turchanyi Geza) Date: Tue, 12 Sep 2000 10:27:22 +0200 (MET DST) Subject: IAB/IESG Recommendations on IPv6 Address Delegation Message-ID: Fred, I would like to add a few comments and a proposal to your marvellous summary. (Even if it is very difficult to say anything at this stage). Comments: 1, The IPv6 address scheme might be valid for two centuries or even longer, and not only for 50 years. 2, The proposed "sparce allocation for subsribers (sites)", "dence allocation for providers (networks)" should work very well for customers, however, not necessarly for providers. You mentioned already the multihoming issues. There is an other open issue: how to scale effectively the routing. Proposal: I suggest adding a clause to your summary: ADDRESS ALLOCATION POLICY will be reviewed every five years. If different address allocation policy will be set up for any reason, then all subscribers and providers having already address space should adopt themselves to the new policy within TEN years, the latest. If they do not adopt, their not properly allocated address space will be blocked from the global routing. Many thanks for your time, best regards, Geza Turchanyi From hph at online.no Tue Sep 12 13:56:58 2000 From: hph at online.no (Hans Petter Holen) Date: Tue, 12 Sep 2000 13:56:58 +0200 Subject: Discussion: Address Council election procedures References: <200008071415.QAA12337@birch.ripe.net> Message-ID: <002801c01cb0$8e702570$a20400c1@hph> On the topic of > Call for Nominations for Representatives to the ASO Address Council - > RIPE NCC Region We have a some desicions to make at the upcoming meeting on - when to do the elections - how to do the elections > 4. Address Council Nominations Process (...) > Nominations should be sent by email to , by midnight > CET on 30 September 2000. (...) Due to the timeconstraints we unfortunately have ended up with we cannot hold the election at RIPE 37 but will have to do it at a later stage. We can either delay the election to RIPE 38 next year, or we can do some sort of electronic voting between the RIPE meeting and the to ICANN meeting in november (as the ICANN meeting in november would be a convenient place gather the Address Council for a meeting to hand over responsibilities from the 3 members potentialy leaving their seats.) My understanding of the consensus from the previous meetings was that electronic voting was felt to be not yet widely deployable technology. But we may want to reconcider that with experiences from the ICANN at large election and perhaps from ARINs and APNICs plans. > 5. Address Council Selection Process > - ------------------------------------ > > The process for selection of the nominee to serve on the Address Council > will involve an open election. Due to the 90 day lead time needed for a call > for nominations prior to a RIPE NCC region policy meeting, the selection > process will not be held at the RIPE 37 meeting, 12-15 September 2000, in > Amsterdam. > > Two selection processes have been proposed. The first follows the voting > process outlined in the MoU. The selection procedure would take place at the > RIPE 38 meeting in January 2001 in Amsterdam. The second process currently > being discussed involves implementing an electronic voting procedure as it > would allow for more participation in the selection process and could > bring the process forward. This procedure would be discussed prior to > the RIPE 37 meeting and announced in the LIR-WG meeting. > Hans Petter Holen, LIR-WG Chair, > will initiate discussions about this procedure on the lir-wg mailing list. > > Important Dates: > > 30 September 2000 - deadline for Address Council nominations Sincerely, Hans Petter Holen lir-wg chair From hph at online.no Tue Sep 12 13:57:59 2000 From: hph at online.no (Hans Petter Holen) Date: Tue, 12 Sep 2000 13:57:59 +0200 Subject: Call for Nominations - ASO Address Council References: <200008071415.QAA12337@birch.ripe.net> Message-ID: <002b01c01cb0$b26b4450$a20400c1@hph> Just a reminder of the ongoing nominations process, and an invitation to nominees and potential nominees: if you want to use this RIPE meeting to present yourselves to the LIR-wg: Please approach me to get on the agenda or if you are not able to make it to the meeting send me, 2-3 slides worth of presentation. Then I, or somebody of your choosing may present to the wg. Depending on the outcome of the election process discussion there will of course also be time to present the nominees to the list before the election. > 4. Address Council Nominations Process > - -------------------------------------- > > The term of Sabine Jaume who has served as an initial AC member for the past > year has expired. One individual from the RIPE NCC Region will be selected to > serve on the Address Council for a term of three years. The selection will be > made through an open election process, from the set of individuals who have > been nominated within this process. > > Any individual may be nominated, with the exception of any staff member of > any Regional Internet Registry. Self-nominations are permitted. > > Nominations should be sent by email to , by midnight > CET on 30 September 2000. > > The information included with the nomination is to be in English, and > should?include: > > Name of Nominee: > Country of residence: > Organisation: > Email Address: > Postal Address: > Biographical information: > Motivation for nomination: > > Name of nominating individual: > Organisation: > Email Address: > > All nominees will be contacted via email to confirm their willingness to > serve on the Address Council. If a nominee cannot be contacted via email, > or does not respond, then their nomination will not be confirmed and they > will not be eligible for election to the Address Council. > > All confirmed nominations will be listed on the RIPE NCC web site after they > are confirmed. All nominees will have the opportunity to submit a written > statement in support of their nomination for publication on the web site. > In addition, others may express support for nominated individuals simply by > completing and submitting the nomination form provided above. (...) > Important Dates: > > 30 September 2000 - deadline for Address Council nominations Regards, Hans Petter Holen lir-wg chair. From hph at online.no Tue Sep 12 14:39:34 2000 From: hph at online.no (Hans Petter Holen) Date: Tue, 12 Sep 2000 14:39:34 +0200 Subject: 2nd Draft Agenda LIR-WG 37 References: <000401bff98a$722e4020$43f5fea9@hph> Message-ID: <00fc01c01cb6$8193da30$a20400c1@hph> 1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters by hostmaster at ripe.net 4. RIPE 35 minutes actions 5. Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. Reports from the other registries APNIC (ARIN sends their appologies) (ICANN) (Status of the LACNIC and AFRI NiCs) 6. Report from the address council by Hans Petter Holen, Wilfried Woeber, Sabine Jaume 7. Report from the 17th of may Task Force by Stephen Burley 8. PGP for hostmaster at ripe.net. (35.4 and 35.5) by Olaf Kolkman 9. Election procedures for the Address Council 10. Presentations of candidates for the AC election 11. Status of the ICANN ad Hoc group 12. RIPE 174 Abitravtion Philip Bridge, Nextra (Schweiz) AG 13. AOB. Note that issues concerning IPv6 policy will be discussed in a separate session. Action list: LIR- Status 35.1 Chair Publish policy document 35.2 Chair publish election procedure 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hm 36.1 Chair Form 17th of May Task Force 36.2 KF/NCC Implement the recommended GPRS policy 36.3 NCC Publish address block allocation sizes by 0615 36.4 NCC Lower minimum allocation size from /19 to /20 not before 0801 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators 36.7 NCC Keep lir-wg updated on pre RIR address space changes From hph at online.no Tue Sep 12 14:56:58 2000 From: hph at online.no (Hans Petter Holen) Date: Tue, 12 Sep 2000 14:56:58 +0200 Subject: Topics for todays ICANN ASO workshop at 1700 Message-ID: <010a01c01cb8$f05b9d70$a20400c1@hph> Dear friends of RIPE; I have asked for a timeslot on this RIPE meeting to have a more informal Worksop style of environment were it is possible for those of you with particular interest in the work going on in the ICANN ASO and in the Address Council in particular. We will of course have a report from the AC in the lir-wg (as usual) and maybe even at the RIPE plenary at the RIPE chairs discretion. My thoughts behind this particular format at this particular meeting is to allow for the possibility of even more preparatory discussions in even more details than we usually have time for. Ideally I would have liked the meeting to happen later in the week, but not even the magic of the RIPE NCC meeting staff was enough for that to happen (we simply have to many competing for the same slots). The following rather broad topics lies on the Address Councils table, and will be discussed by the AC, ICANN and the RIRs at a physical AC meeting in Brisbane just after the APNIC meeting in October. This effort is thus an attempt to seek advice from the community before these discussions to satisfy the basic requirements for openness and transparency. 1) What is global policy ? There are several dimensions to this discussion: - replace RFC 2050 with a ICANN Address policy document - what is the distinction between regional and global policy - do we understand and appreciate the differences between the regional policies ? - differences between v4 and v6 with respect to the last item - what's the role/work mode of the AC ? to make the definite address policy, or to work on issues as they show up - were is the border between a service level contract and policy issues. - are there other operating guidelines for the ICANN - IANA than the global addressing policy ? 2) Revising the MOU In the widest sense: are there things in the present MOU that needs more work and needs to be changed ? 3) Addressing the essence of the ad Hoc committee, i.e. discussing how to best address new addressing needs emerging for 4) How to promote ipv6 ? 5) Emerging RIRs How to enable and support the emerging RIRs to establish regional policy processes ? The discussions in just above an hour needs not be limited to these topics. So, if you have a particular interest in influencing your AC members thinking on these or other matters, be there ! Sincerely, Hans Petter Holen Address Council Chair From hph at online.no Tue Sep 12 15:13:26 2000 From: hph at online.no (Hans Petter Holen) Date: Tue, 12 Sep 2000 15:13:26 +0200 Subject: Discussion: Address Council election procedures References: <74492.968760153@critter> Message-ID: <011e01c01cbb$3cb28b50$a20400c1@hph> > >My understanding of the consensus from the previous meetings was that > >electronic voting was felt to be not yet widely deployable technology. > >But we may want to reconcider that with experiences from the ICANN > >at large election and perhaps from ARINs and APNICs plans. > > I would actually argue that electronic voting is preferred because it > will allow people unable to participate in RIPE meetings to vote as > well. I agree with you but the trouble we ran into when discussiong this at a previous meeting was that it is easy to define the electorate (who gets to vote) if we do the voting at a meeting; then we have an open meeting for anyone to participate, and thoose present may vote (with the restrictions set forth in bylaws and MoUs preventing RIPE NCC staff to do so.) If we should go for electronic voting, we could either stay OPEN and allow anyone on the internet (or on the internet in the RIPE region ( or on the internet with interests in the RIPE region)) to vote. Or we may want to limit that to the "RIPE membership" which is and always has been non existent. (Not to be confused with the RIPE NCC Association membership) Now theese difficulties needs to be taken into account, just as your pont that electronic voting would allow thoose not able to get to the RIPE meeting to participate. -hph From phk at critter.freebsd.dk Tue Sep 12 14:02:33 2000 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 12 Sep 2000 14:02:33 +0200 Subject: Discussion: Address Council election procedures In-Reply-To: Your message of "Tue, 12 Sep 2000 13:56:58 +0200." <002801c01cb0$8e702570$a20400c1@hph> Message-ID: <74492.968760153@critter> In message <002801c01cb0$8e702570$a20400c1 at hph>, "Hans Petter Holen" writes: >My understanding of the consensus from the previous meetings was that >electronic voting was felt to be not yet widely deployable technology. >But we may want to reconcider that with experiences from the ICANN >at large election and perhaps from ARINs and APNICs plans. I would actually argue that electronic voting is preferred because it will allow people unable to participate in RIPE meetings to vote as well. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From phk at critter.freebsd.dk Tue Sep 12 15:23:25 2000 From: phk at critter.freebsd.dk (Poul-Henning Kamp) Date: Tue, 12 Sep 2000 15:23:25 +0200 Subject: Discussion: Address Council election procedures In-Reply-To: Your message of "Tue, 12 Sep 2000 15:13:26 +0200." <011e01c01cbb$3cb28b50$a20400c1@hph> Message-ID: <76915.968765005@critter> In message <011e01c01cbb$3cb28b50$a20400c1 at hph>, "Hans Petter Holen" writes: >> >My understanding of the consensus from the previous meetings was that >> >electronic voting was felt to be not yet widely deployable technology. >> >But we may want to reconcider that with experiences from the ICANN >> >at large election and perhaps from ARINs and APNICs plans. >> >> I would actually argue that electronic voting is preferred because it >> will allow people unable to participate in RIPE meetings to vote as >> well. > >I agree with you but the trouble we ran into when discussiong this at a >previous meeting was that it is easy to define the electorate (who gets to >vote) One LIR one vote ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk at FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD coreteam member | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From maldwyn at ripe.net Tue Sep 12 16:18:29 2000 From: maldwyn at ripe.net (Maldwyn Morris) Date: Tue, 12 Sep 2000 16:18:29 +0200 Subject: ANNOUNCEMENT: Rttquery Web Page updated Message-ID: <200009121418.QAA27646@birch.ripe.net> Hi, The RIPE NCC provides information to its members on the processing of their request tickets via the Rttquery Web Page: http://www.ripe.net/cgi-bin/rttquery This is to let you know that we have updated the page to show the given ticket's relative position in the Wait Queue, where it is put before it is given to a Hostmaster. We also now show customer labels in the ticket's messages. Any text in the Subject of a message between the opening delimiter: #{ and the closing delimiter: #} is displayed next to that message. Please let me know if you have any questions about this web page. Cheers, Maldwyn Morris maldwyn at ripe.net Software Manager RIPE NCC From asadchik at mtu.ru Tue Sep 12 19:28:40 2000 From: asadchik at mtu.ru (asadchik at mtu.ru) Date: Tue, 12 Sep 2000 19:28:40 Subject: Discussion: Address Council election procedures References: <76915.968765005@critter> Message-ID: May be one AS one vote? It will be much more representativ... --- On Tue, 12 Sep 2000 15:23:25 +0200 Poul-Henning Kamp wrote: > In message <011e01c01cbb$3cb28b50$a20400c1 at hph>, "Hans Petter Holen" writes: > >> >My understanding of the consensus from the previous meetings was that > >> >electronic voting was felt to be not yet widely deployable technology. > >> >But we may want to reconcider that with experiences from the ICANN > >> >at large election and perhaps from ARINs and APNICs plans. > >> > >> I would actually argue that electronic voting is preferred because it > >> will allow people unable to participate in RIPE meetings to vote as > >> well. > > > >I agree with you but the trouble we ran into when discussiong this at a > >previous meeting was that it is easy to define the electorate (who gets to > >vote) > > One LIR one vote ? > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk at FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD coreteam member | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > ---------------End of Original Message----------------- Regards, Alexey Sadchikov --------------------------------------------------------------------+ MTU-Intel company, E-mail: asadchik at mtu.ru I Technical Director Phone +7 095 258-7839,7878 I Date: 09/12/00 Time: 19:28:40 FAX +7 095 258-7870 I --------------------------------------------------------------------+ From maldwyn at ripe.net Tue Sep 12 18:42:35 2000 From: maldwyn at ripe.net (Maldwyn Morris) Date: Tue, 12 Sep 2000 18:42:35 +0200 Subject: ANNOUNCEMENT: Beta Version of ASinuse Web Page Message-ID: <200009121642.SAA13466@birch.ripe.net> Hi, The RIPE NCC are please to announce a Beta Version of the ASinuse Web Page, available via the page: http://www.ripe.net/ripencc/pub-services/np/ris-index.html ASinuse lets users look up any AS number in the RIS database to show its observed peers and the time at which they were observed, and to further query those peers. Please let me know if you have any questions about this web page. Cheers, Maldwyn Morris maldwyn at ripe.net Software Manager RIPE NCC From hph at online.no Tue Sep 12 19:58:25 2000 From: hph at online.no (Hans Petter Holen) Date: Tue, 12 Sep 2000 19:58:25 +0200 Subject: 3nd Draft Agenda LIR-WG 37 References: <000401bff98a$722e4020$43f5fea9@hph> <00fc01c01cb6$8193da30$a20400c1@hph> Message-ID: <017f01c01ce3$0d07e8f0$a20400c1@hph> 1. Admin scribe, participant list, charter, mailinglists 2. Agenda 3. Meet the RIPE NCC hostmasters by hostmaster at ripe.net 4. RIPE 35 minutes actions 5. Report from the RIPE NCC Hostmasters by Nurani Nimpuno 5. Reports from the other registries APNIC (ARIN sends their appologies) (ICANN) (Status of the LACNIC and AFRI NiCs) 6. Report from the address council by Hans Petter Holen, Wilfried Woeber, Sabine Jaume 7. Restoring the transparency by Masataka Otha 8. Report from the 17th of may Task Force by Stephen Burley 9. PGP for hostmaster at ripe.net. (35.4 and 35.5) by Olaf Kolkman 10. Election procedures for the Address Council 11. Presentations of candidates for the AC election 12. Status of the ICANN ad Hoc group 13. RIPE 174 Abitravtion Philip Bridge, Nextra (Schweiz) AG 14. AOB. Note that issues concerning IPv6 policy will be discussed in a separate session. Action list: LIR- Status 35.1 Chair Publish policy document 35.2 Chair publish election procedure 35.4 NCC PGP Key exchange procedure 35.5 NCC Implement PGP for hm 36.1 Chair Form 17th of May Task Force 36.2 KF/NCC Implement the recommended GPRS policy 36.3 NCC Publish address block allocation sizes by 0615 36.4 NCC Lower minimum allocation size from /19 to /20 not before 0801 36.5 Chair Assignment window applied on infrastructure 36.6 AP Collect arbitrators 36.7 NCC Keep lir-wg updated on pre RIR address space changes From hph at online.no Wed Sep 13 09:58:28 2000 From: hph at online.no (Hans Petter Holen) Date: Wed, 13 Sep 2000 09:58:28 +0200 Subject: Discussion: Address Council election procedures References: <200008071415.QAA12337@birch.ripe.net> <002801c01cb0$8e702570$a20400c1@hph> Message-ID: <007601c01d58$676bf5f0$a20400c1@hph> Just to give you all the full picture, here is the consensus from the lir-wg as reported to the RIPE 35 plenary: Establish Final Selection Procedure for the Address Council Nominations. . Well in advance of the election . Candidates may present themselves at the budapest ripe meeting . At the mailinglist . At the autumn RIPE meeting . Mechanism for others to express support Who can vote ? . Not only RIPE NCC association members, but all members of the RIPE community . Everybody present at a RIPE meeting may vote . Due to restrictions in the MOU RIR staff cannot be elected or vote. Voting procedure: . Secret ballot at the RIPE meeting plenary . One vote pr seat to fill . The person(s) with most votes is elected Summary .Open: this procedure will be published well in advance on the mailinglist .Transparent: the whole process is known and takes part on the meetings .Simple: it is easy to understand and easy to have confidence in the process Sincerely, Hans Petter Holen lir-wg Chair From fred at cisco.com Wed Sep 13 15:51:08 2000 From: fred at cisco.com (Fred Baker) Date: Wed, 13 Sep 2000 06:51:08 -0700 Subject: IAB/IESG Recommendations on IPv6 Address Delegation In-Reply-To: Message-ID: <5.0.0.25.2.20000913064937.023a9810@flipper.cisco.com> At 10:27 AM 9/12/00 +0200, Turchanyi Geza wrote: >ADDRESS ALLOCATION POLICY will be reviewed every five years. If different >address allocation policy will be set up for any reason, then all >subscribers and providers having already address space should adopt >themselves to the new policy within TEN years, the latest. If they do not >adopt, their not properly allocated address space will be >blocked from the global routing. that's probably not unreasonable. However, that's not mine to say, I don't think. IETF advises the RIRs, and from them the operators and subscribers, on how to pass out the addresses. After that, actual use is in the RIRs' and operators' hands. From hph at online.no Fri Sep 15 12:49:52 2000 From: hph at online.no (Hans Petter Holen) Date: Fri, 15 Sep 2000 12:49:52 +0200 Subject: LIR-WG Plenary report Message-ID: <004801c01f02$ad7956e0$a20400c1@hph> Dear workinggroup, As we ran seriously out of time both in the workinggroup itself and in the plenary report, I am posting my slides for you all to view for the full report. It will soon also be up on the RIPE web site. http://home.online.no/~hph/RIPE Sincerely, Hans Petter Holen From maldwyn at ripe.net Fri Sep 22 12:04:25 2000 From: maldwyn at ripe.net (Maldwyn Morris) Date: Fri, 22 Sep 2000 12:04:25 +0200 Subject: ANNOUNCEMENT: Public Release of Asused Message-ID: <200009221004.MAA09379@birch.ripe.net> Hi, The RIPE NCC are pleased to announce the release of a new public version of Asused - this is Version 3.52. Asused is a tool to check and summarise address space registered in the RIPE database. For a given list of allocations the tool prints various information concerning the allocations and the assignments they contain. The software is written in standard Perl 5 and uses several Perl modules. It was written and tested on BSD/OS 3.1, but should work with any modern UNIX-like operating system. All the files needed are stored in this file: ftp://ftp.ripe.net/tools/asused-3.52.tar.gz or alternatively, just: ftp://ftp.ripe.net/tools/asused-latest.tar.gz You will need to use gzip and tar to extract them, then please follow the instructions in the README file. The changes since Version 3.51 are: * No longer designated as beta software. * Fixed problem with huge free address space reports, caused by bug in the Whois DB - "-Tin" returns rev-srv: A.B.C.D fields as well. * Fixed problem with RIPEWhois.pm module, which didn't return anything on some Linux'es. Was reported several times, visible effect was: FATAL ERROR: ERROR: 10.65.0.0/19 No allocation object in DB, inetnum found * Fixed small compatability problem - some systems don't let to use IO::Socket::INET directly, so, turned that into "use IO::Socket". * Put the CPAN IO module IO-1.20.tar.gz into extra/ directory, as some Perl distributions come with outdated modules and CPAN suggests perl5.6.0 as an update :> * Added --free flag to show only free address space list. * Produce a warning if a registry doesn't have mnt-lower attribute on it's allocation. * Fixed the case that --status didn't report assignments with missed status lines and gave incorrect balance. Thanks to the following people for bug reports and suggestions: Elmar K. Bins Jean-Francois Stenuit Dominic Mitchell Daniel N. Rasmussen Johannes Dagemark Timur Bakeyev of RIPE NCC did the programming. We are keen to receive your further feedback on this software - please address your comments and/or suggestions to me. Cheers, Maldwyn Morris maldwyn at ripe.net Software Manager RIPE NCC