- lir-wg - mailman.ripe.net

Re: New Assignment Window Policy implemented
by Sabrina Waschke 17 Dec '01

17 Dec '01

Gert Doering <gert(a)space.net> writes: * Hi, * * On Sat, Dec 15, 2001 at 01:58:13AM +0200, Yiannis Samouhos wrote: * > Are you sure this is correct?? * > * > Is it INFRA-AW or INTRA-AW? * * I'd guess "INFRA", for "INFRAstructure assignment". Correct. Sabrina Waschke RIPE NCC * Gert Doering * -- NetMaster * -- * Total number of prefixes smaller than registry allocations: 72790 (73802) * * SpaceNet AG Mail: netmaster(a)Space.Net * Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 * 80807 Muenchen Fax : +49-89-32356-299 *

1 0

New Assignment Window Policy implemented
by Sabrina Waschke 16 Dec '01

16 Dec '01

[Apologies for duplicate mails] Dear all, At RIPE 40 in Prague (October 2001) the RIPE community changed the Assignment Window (AW) Policy. (see http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/lir-wg-40/ index.html) The previous AW policy: "The assignment window is the maximum number of addresses that can be assigned by the local IR to an end user without prior approval by the RIPE NCC. This is expressed in /nn notation. Therefore, a local IR with an assignment window of /23 is allowed to assign up to and including 512 addresses to an end user without prior approval of the RIPE NCC. As the Local IR staff gain experience, the window size is increased... ...The assignment window is not only applied to individual assignments, but to multiple assignments to the same end user in a 12 month period If a Local IR makes more than one assignment to an organisation in any 12 month period, the total amount of address space assigned may not exceed the Local IR's assignment window. This also applies to address space used by the Registry for their internal network. Additional address space can only be assigned to that organisation after approval by the RIPE NCC." (see http://www.ripe.net/ripe/docs/ir-policies-procedures.html#toc39) The problem: This AW policy also applied to address space used by the Local Internet Registry (LIR) for their internal network. A registry that mainly assigns addresses to their own network would not be able to make the majority of the assignments to themself using their AW as the AW only applies once every 12 months. The new AW policy: Consensus was reached in the LIR Working Group to change this policy so that the LIR can make multiple assignments to their own infrastructure without contacting the RIPE NCC as long as the individual assignment is within their Assignment Window. The Implementation: Assignments made to the LIR's infrastructure using this new AW policy must have a remarks attribute in the inetnum object with the value INFRA-AW. It is important that a seperate remarks attribute is used for this. No other comment may be included in this line. It is possible to have other remarks attributes in the same object, though. The Audit: The existing audit policy allows the RIPE NCC to review your assignments at any time in order to assure a fair distribution of address space. It was agreed that the RIPE NCC may request proper documentation and an overview of the address space used for the LIR's own infrastructure. "If the LIR fails to show decent documentation the RIPE NCC may lower the LIR's Assignment Window. As this may delay the new allocation of addresses somewhat, the LIRs should be prepared to produce proper documentation upon request." (see http://www.ripe.net/ripe/meetings/archive/ripe-40/presentations/lir-wg-40/s… 3.html) This new AW policy will be implemented as of Monday, 17th December 2001. If you do not want to use this new facility you are welcome to continue submitting requests to the RIPE NCC. For any questions regarding your AW please contact the RIPE NCC via <lir-help(a)ripe.net> including your Reg ID. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o

4 3

IP Request Tutorial during the RIPE 41 meeting in Amsterdam
by Vesna Manojlovic 14 Dec '01

14 Dec '01

Dear colleagues, During the RIPE 41 Meeting, an "IP Request Tutorial" will be held on Friday, 18 January, from 2 PM till 5.30 PM. The goal of the "IP Request Tutorial" is to explain address space assignment and allocation procedures. It contains selected parts from the LIR course that RIPE NCC provides to its members: How to Interact with the RIPE whois Database How to Request Address Space - Completing the Request Form - Evaluation Assignment Window PI Assignments How to Request New Allocation It is not necessary to register. All RIPE meeting participants are more than welcome to attend this tutorial. More information about the course that RIPE NCC offers to its members is available at http://www.ripe.net/training/ Material is available at the RIPE Meeting web pages: http://www.ripe.net/ripe/meetings/current/ripe-41/tutorials/ip_request.html Regards, Vesna Manojlovic RIPE NCC Trainer

1 0

[apnic-announce] Additional IPv4 address range 220/8 allocated to APNIC
by Sabrina Waschke 10 Dec '01

10 Dec '01

Dear Colleagues, Please see the announcement below. Sabrina Waschke RIPE NCC ------- Forwarded Message Date: Fri, 7 Dec 2001 10:25:55 +1000 (EST) From: George Michaelson <ggm(a)apnic.net> Sender: owner-apnic-announce(a)lists.apnic.net To: apnic-announce(a)whois.staff.apnic.net Subject: [apnic-announce] Date: Fri, 07 Dec 2001 10:25:53 +1000 [Note "reply-to:" field] - ------------------------------------------------- APOLOGIES for multiple copies. Dear colleagues APNIC received the IPv4 address range 220/8 from IANA on 2nd December 2001 and will now begin making allocations from this range. Please configure your routing filters accordingly. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards APNIC Secretariat <secretariat(a)apnic.net> - ------------------------------------------------- * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request(a)apnic.net * ------- End of Forwarded Message

1 0

Call for Nominations to ICANN Board of Directors
by Paul Rendek 10 Dec '01

10 Dec '01

Dear colleagues, We are pleased to announce a Call for Nominations to the ICANN Board of Directors (see below). In our effort to reach as many interested parties as possible you may receive multiple copies of this message. Please accept our apologies for this. The Call for Nominations for ICANN Board of Directors and current appointments to the Board can be found on the ASO website at: http://www.aso.icann.org/ A publicly archived "expressions of support" form will be made available on the ASO website for those that wish to support nominated candidates. Regards, Paul Rendek RIPE NCC ===== ASO General Assembly 2002 and Call for Nominations for ICANN Board of Directors The Address Council of the Address Supporting Organisation is pleased to announce the 3rd ASO General Assembly meeting, to be held on Tuesday, 5 March 2002 in Bangkok, Thailand. This meeting will be hosted by APNIC alongside APNIC's Open Policy Meeting, and will be open to all parties with an interest in ASO policy matters. A detailed meeting agenda will be published in due course on the ASO web site at: http://www.aso.icann.org. In compliance with the ASO MoU <http://www.aso.icann.org/docs/aso-mou.html>, the Address Council and ICANN hereby call for nominations to the ICANN Board to fill vacant ASO seats on the ICANN Board. The first such seat scheduled to become vacant on 1 October 2002 is currently occupied by Mr. Rob Blokzijl. However, candidates nominated at this time may also be chosen to fill other seats that may become vacant before or after this time. Note that appointments to the ICANN board must satisfy the geographic diversity constraints specified in section 3c. of the ASO MoU. Any individual may be nominated within this process, with the exception of any official of a national government or a multinational entity established by treaty or other agreement between national governments (ICANN Bylaws Art. V., Sec 5). Self-nominations are permitted. Nominations should be sent by email to <secretariat(a)aso.icann.org> and should state the following details : A. Nominee details 1. Full name 2. Organisational affiliation 3. Email address 4. Physical address 5. Country of residence 6. Telephone contact 7. Biography B. Details of nominating individual 1. Full name 2. Organisational affiliation 3. Email address 4. Country of residence Nominations must be submitted in English and must be received by the ASO Secretariat before 0900 UTC, 6 February 2002 (30 days prior to the General Assembly meeting). All nominees will be contacted via email to confirm their willingness to serve as an ICANN Director. If the nominee is not contactable via email then the nomination will not be confirmed, a nominee must explicitly confirm the nomination to the ASO Secretariat to be considered as a candidate. All confirmed nominations will be listed on the ASO website (see http://www.aso.icann.org) as soon as they are confirmed. Those wishing to express support for any individuals who have been nominated should use the "ICANN Board - Support of Nomination" Form which will be made available on the ASO website. The list of nominated individuals and the supporting comments will be passed to the Address Council after all nominees are confirmed, and prior to the General Assembly meeting on 5 March 2002. More information regarding the ASO GA and nominations process will be posted on the ASO website <http://www.aso.icann.org> in due course.

2 1

2nd reminder RIPE 41 registration
by RIPE NCC Meeting Registration 10 Dec '01

10 Dec '01

Dear Colleagues, Herewith we like to remind you of the registration for the RIPE 41 meeting which has been opened. The meeting will be held from 14th January - 18th January 200 2 at hotel Krasnapolsky in Amsterdam, The Netherlands. More information about this meeting and accommodations can be found on this page: http://www.ripe.net/ripe/meetings/current/ripe-41/ Online registration will open on Monday 19th November 2001 and close on Friday 4th January 2002. On-site registration will open on Monday 14th January 2002. Please note the following: To avoid waiting queues at the registration desk on-site we encourage pre-payment by credit card. The registration fee for this meeting is EUR 350.00 (this includes refreshments and lunches) and the dinner fee is EUR 65.00. However, if payment is received before 4 January 2002, the pre-payment cut-off date, you will receive a pre-registration discount of EUR 50.00. Therefore, the fee for attendees paying before the cut-off date is EUR 300.00 for the meeting and 65.00 EUR for the RIPE dinner event. Confirmation of Registration: For your convenience you can register using our secure website at: https://www.ripe.net/cgi-bin/mtgreg (encrypted form) http://www.ripe.net/cgi-bin/mtgreg (non-encrypted form) If you still prefer not to send your credit card number using an encrypted transfer method, we have prepared a fax form. This form is attached to the acknowledgment of your registration. You will receive a second acknowledgment by e-mail as soon your payment has been processed. In addition, you will find the receipt for your payment in your conference envelope. Participants requiring a visa to enter The Netherlands are advised to begin the required procedures as soon as possible. The RIPE Meeting organizers are pleased to provide letters of invitation to those attendees requiring them. Should you have any further questions, please do not hesitate to contact us at <meeting(a)ripe.net>. Kind regards, Asha Raghoebarsing RIPE Meeting Co-ordinator <meeting(a)ripe.net> ------- End of Forwarded Message

1 0

Problems with RIPE NCC Robots
by Manuel Valente 06 Dec '01

06 Dec '01

Dear members, The RIPE NCC request handling system had a few problems today (December 6) which may cause delays in the processing of the wait queue. Some of the requests could not be automatically processed and may have resulted in mail errors being returned to the requester. We are now manually processing the requests which we received. However, if you sent a request today and did not receive an acknoledgement, it is possible that your request was deleted. In that case, please resend your e-mail. Please accept our apologies for this problem - we are working on a fix to prevent the problem from happening again. -- Manuel Valente - Software Manager - RIPE NCC

1 0

mnt-routes in allocation objects
by Sabrina Waschke 05 Dec '01

05 Dec '01

Dear all, This is to inform you that the RIPE NCC Registration Services will update all inetnum objects representing allocations made by the RIPE NCC to Local IRs (status: ALLOCATED PA") adding a mnt-routes attribute. We will use the maintainer specified in the mnt-lower attribute of the particular inetnum object. We will only add a mnt-routes attribute to allocation objects that have exactly one mnt-lower attribute (*). The updates will start on Monday, 10th December 2001. Until the introduction of RPSL there was no mnt-routes attribute. Adding a mnt-routes attribute to the inetnum object representing your allocation will enable you to create route objects matching the exact size of your allocation object. (You might have to pass other authorisations.) For a graphical overview of "Route Object Creation - Getting Authorisation from IP Space" please see: <http://www.ripe.net/ripencc/faq/database/route-creation-IP-space-c heck.html>. For more information about route object please read: <http://www.ripe.net/ripe/docs/databaseref-manual.html#1.2.15> and <http://www.ripe.net/ripe/docs/databaseref-manual.html#3.6.5>. (*) In general: If you want to update an object maintained by the RIPE-NCC-HM-MNT please send a message to <lir-help(a)ripe.net> including your registry ID and the revised object. Please note that we only accept these requests from official LIR contacts who are registered in our RIPE NCC internal registry files. If you have any further questions please do not hesitate to contact <lir-help(a)ripe.net> including your registry ID. Kind regards, Sabrina Waschke -- o------------------------------------------o | Sabrina Waschke sabrina(a)ripe.net | | Registration Services Operations Manager | | | | RIPE NCC tel +31 20 535 4444 | | www.ripe.net fax +31 20 535 4445 | o------------------------------------------o

1 0

Can anyone shed some light on this?
by Stephen Burley 05 Dec '01

05 Dec '01

route: 212.249.0.0/16 descr: UUNET CH origin: AS702 mnt-by: AS702-MNT password: ********* changed: jsc(a)ch.uu.net 20011204 source: RIPE I send the above object to the DB and get the following error: New FAILED: [route] 212.249.0.0/16 route: 212.249.0.0/16 descr: UUNET CH origin: AS702 mnt-by: AS702-MNT changed: stephenb(a)uk.uu.net 20011204 source: RIPE ***Error: Hierarchical authorisation failed, request forwarded to maintainer. Objects in RIPE-181 format are no longer accepted. Please see http://www.ripe.net/rpsl for more information. RIPE Database Maintenance Department Which is strange as the mainainer is us AS702-mnt. Any help on this matter whould be appreciated as this is not the only one. Regards Stephen Burley UUNET EMEA Hostmaster SB855-RIPE

5 6

RE: Can anyone shed some light on this?
by Boyan Krosnov 05 Dec '01

05 Dec '01

http://www.ripe.net/ripe/docs/databaseref-manual.html 3.6.5 Protection of route object space The route object creation must satisfy several authentication criteria. It must match the authentication specified in the aut-num and the authentication specified in either a route object or, if no applicable route object is found, then an inetnum. Finally the creation must be authorised by the maintainer of the route object itself referenced by the "mnt-by:" attribute of the object. When checking for prefix authorisation, an exact route object prefix match is checked for first. If there is no exact match, then a longest prefix match that is less specific than the prefix is searched for. If the route prefix search fails, then a search is performed for an inetnum object that exactly matches the prefix or for the most specific inetnum object that is less specific than the route object submission. The aut-num object used for authentication checks is referenced by the "origin:" attribute of the route object. A route object must pass authorisation from both the referenced aut-num object and the route or inetnum object. Authorisation shall be tested using the maintainer(s) referenced in the "mnt-routes:" attribute(s) first. If that check fails, the "mnt-lower:" attributes are checked. If that check fails, the "mnt-by:" attributes are used for the authorisation check. ---------- aut-num: AS702 as-name: AS702 descr: UUNET - Commercial IP service provider in Europe .... mnt-routes: UUNETDK-MNT mnt-routes: AS1270-MNT mnt-routes: AS1849-MNT mnt-routes: AS1890-MNT mnt-routes: IWAY-NOC mnt-by: UUNET-MNT --------- I bet you didn't pass this authorization check. does this shed a light? :) BR, CCNP Boyan Krosnov Network Administrator Lirex Net phone: +359-2-91815 > -----Original Message----- > From: Stephen Burley [mailto:stephenb@uk.uu.net] > Sent: Wednesday, December 05, 2001 12:30 PM > To: lir-wg(a)ripe.net > Cc: db-wg(a)ripe.net > Subject: Can anyone shed some light on this? > > > route: 212.249.0.0/16 > descr: UUNET CH > origin: AS702 > mnt-by: AS702-MNT > password: ********* > changed: jsc(a)ch.uu.net 20011204 > source: RIPE > > I send the above object to the DB and get the following error: > > New FAILED: [route] 212.249.0.0/16 > route: 212.249.0.0/16 > descr: UUNET CH > origin: AS702 > mnt-by: AS702-MNT > changed: stephenb(a)uk.uu.net 20011204 > source: RIPE > ***Error: Hierarchical authorisation failed, request forwarded to > maintainer. > > Objects in RIPE-181 format are no longer accepted. > Please see http://www.ripe.net/rpsl for more information. > > RIPE Database Maintenance Department > > Which is strange as the mainainer is us AS702-mnt. Any help > on this matter > whould be appreciated as this is not the only one. > > Regards > Stephen Burley > UUNET EMEA Hostmaster > SB855-RIPE > > > >

1 0