February 1995 - lir-wg - mailman.ripe.net

Alert: Banque Nationale de Paris
by RIPE NCC Hostmaster 01 Mar '95

01 Mar '95

Hi, We have received requests for IP address space from various sources for the Banque Nationale de Paris, in various countries. Since it looks like they are shopping around, and they already have a substantial amount of address space, we would like you to refer them to the RIPE NCC if they apply at your registry. Thank you. Geert Jan

3 2

Re: Draft minutes of meeting at RIPE 20
by Geoff Huston 23 Feb '95

23 Feb '95

> 11. Tools > > - Geert Jan reported that 70% of the reverse domain delegation > requests contain errors in their set up and are returned to > the sender. The French NIC is developing a tool (Christophe > Chaillot) which does some error checking. The tool will be > distributed once it is finished. > >I think the name for the author of this tool should be mine (Benoit >Grange). Mr Chaillot is working at France Telecom and not in the >french Nic. > >By the way, this tool is getting closer to a release line, but I still >have to implement other language support (It is in french today). I >will send an e-mail in the group when it will be ready. have a look at http://www.aarnet.edu.au/aunic/inaddr-template.html (yes it's in english - but the procedure does the checks for correct configuration of the nominated servers) Geoff

1 0

Re: Draft minutes of meeting at RIPE 20
by Mike Norris 22 Feb '95

22 Feb '95

Benoit is obviously right about this, and I'm sorry for letting the error slip through. I'll ask the scribe to change the minutes accordingly. (OK, David?). Mike ------- Forwarded Message Return-Path: Benoit.Grange(a)inria.fr Received: from vespucci.inria.fr (vespucci.inria.fr [128.93.2.27]) by ftp.inria.fr (8.6.8/8.6.6) with ESMTP id PAA23003; Tue, 21 Feb 1995 15:51:39 +0100 Received: (from grange@localhost) by vespucci.inria.fr (8.6.8/8.6.6) id PAA15477; Tue, 21 Feb 1995 15:47:50 +0100 Date: Tue, 21 Feb 1995 15:47:50 +0100 From: Benoit Grange <Benoit.Grange(a)inria.fr> Message-Id: <199502211447.PAA15477(a)vespucci.inria.fr> To: mnorris(a)dalkey.hea.ie Cc: nic(a)nic.fr In-Reply-To: <9502211210.AA16679(a)dalkey.hea.ie> (mnorris(a)dalkey.hea.ie) Subject: Re: Draft minutes of meeting at RIPE 20 Status: O Hello, thank you for the minutes of the local-ir meeting. I have seen a small error in the following paragraph: 11. Tools - Geert Jan reported that 70% of the reverse domain delegation requests contain errors in their set up and are returned to the sender. The French NIC is developing a tool (Christophe Chaillot) which does some error checking. The tool will be distributed once it is finished. I think the name for the author of this tool should be mine (Benoit Grange). Mr Chaillot is working at France Telecom and not in the french Nic. By the way, this tool is getting closer to a release line, but I still have to implement other language support (It is in french today). I will send an e-mail in the group when it will be ready. - -- Benoit Grange NIC France E-Mail: nic(a)nic.fr Personnal E-Mail : Benoit.Grange(a)inria.fr ------- End of Forwarded Message

1 0

Draft minutes of meeting at RIPE 20
by mnorris＠dalkey.hea.ie 21 Feb '95

21 Feb '95

RIPE 20, Amsterdam January 25-27th, 1995 Chairman : Mike Norris 2nd draft - Local IR working group minutes 1. Introduction Mike Norris, the chairman welcomed the participants to the Local IR meeting. Anne Lord volunteered as scribe to take the minutes. The group met twice, for 1.5 hours each meeting. Proposed alterations to the agenda are below: - start with items 1, 2 and 3 on the agenda - follow item 3 with item 12. (will be reported as per scheduled agenda order) 2.1 RIPE 19 minutes There were no changes to the minutes as previously circulated. 2.2 RIPE 19 actions 18.3 done : Geert Jan de Groot Investigate monthly publication of error files on reverse zone files, similar to the host count error files. 19.2 closed : Mike Norris At the 20th meeting to raise the training of local IR's as a topic for discussion. 19.3 open : Daniel Karrenberg To make an inventory document of the problems associated with charging for address space. 19.4 closed : Daniel Karrenberg To recirculate draft proposal on use of private address space for VSE's not connecting to the Internet. Circulate proposal to the WG mailing list. 19.5 closed : RIPE NCC To organise a meeting between regional registries, with representatives from the RIPE local - IR working group. 19.6 closed : Geert Jan To document new attribute "status" proposed to describe whether a network is delegated, reserved or assigned. 19.7 open : RIPE NCC Circulate revised ripe-115 to the local-ir mailing list for comments. 19.8 open : Daniel Karrenberg To prepare specification for the format of the list of service providers. 3. Reports from Regional Registries There was an open invitation to all local registries to contribute under this agenda item. 3.1 Kim Hubbard - InterNIC Kim Hubbard reported on the IP registry activities of the InterNIC, giving also some background information about how their operation is organised. Overview statistics: - 3 staff handle 3000 - 4000 requests per month. - Each staff member handles approx 20-30 telephone calls per working day. - They handle approximately 5000/month allocations and assignments to ISP's. - 2000/month single and small block assignments. - Class B assignments are running at 20/month. This has been quite stable for some time. Address Justifications requested: class B's - min 10% utilisation expected - subnet mask plans - network diagrams class C's - CIDR blocks to ISP's gradual increase in allocations "handholding" procedure will be initiated in the future. - subnetting plans - host/subnet counts The procedure of referring small ISP's to larger ones for address space will change. Additional Services by IP Numbers Group - shared WHOIS project approximately 2000 reassignments/month - inverse address registration approximately 500 delegations/month - AS number allocation approximately 60/month currently not a lot of justification is required by requestors Current Issues facing the InterNIC - rfc1597/1627 policy on encourage its usage or not - single low host requests - "portable" addresses - ISP allocation guidelines - ISP's want to see these in writing - registry guidelines - the InterNIC is working with other Regional Registries in this area to coordinate and streamline efforts A copy of the presentation can be found in the presentations directory: ftp://ftp.ripe.net/ripe/presentations/xxxxxx kim nagged 3.2 RIPE NCC Report - Daniel Karrenberg The slides of Daniels presentation were part of the RIPE NCC Report which was presented in the plenary session, which are available from ftp://ftp.ripe.net/ripe/presentations/xxxxx nag dfk Overall the statistics shown in the report reflect the expected linear growth of the Internet with respect to DNS, the number of local IR's, It is expected that there will be around 240 local IR's by the end of 1995. The current breakdown is as follows: Enterprise Registry: 14 Last Resort Registry: 31 Provider Registry: 103 of which: 17 are large 29 are medium 57 are small It is clear that the growth curve of the number of new local registries in increasing. The new registries require more and more support and guidance and are a significant load factor on the RIPE NCC. However, the up side is that they should provide more income in the long term. The number of incoming messages to hostmaster is increasing and is now averaging around 37 messages a day. The workload and growth is such that this now accounts for more than 50% of staff time, leaving very little time for other needed activities. The staff situation is improving - now 4.5 FTE's, but is not enough to cope with the pace of growth. With reference to the invoicing for 1994, some erroneous bills have been sent for which Daniel apologised. In terms of activities over the last quarter, the RIPE NCC is just "keeping up". A better billing mechanism has been implemented, new classless db is running well, there has been internal reorganisation and new staff have to be trained. In the questions that followed, Daniel made it clear that the workload of the registry work was such that it had become clear that there was a need for a ticketing system that integrated with mail was needed. On this there was a request to the participants for input - Mark Kosters of the InterNIC has developed an in-house tool that might be useful although it is still under development. There was a question concerning the criteria for local registries: whether they were still the same as those stated in ripe-104. In response, Daniel noted that because of the very high number of new local registriess, the procedures for management of the address space with respect to the local registries has been tightened. Basically now, all new registries follow a "handholding" procedure with an assignment window of 0 which increments to larger amounts over time. Ripe-104 will be revised to reflect this. There was also a question regarding the newer "Enterprise Registries" and who qualifies in this respect. Enterprise Registries are those which coordinate the address space deployment for an organisation. One of the criteria to determine "eligibility" is the existence of a large corportate networking division within that Enterprise. It was felt that written guidelines were needed in this respect and that these should go into the next revision of ripe-104. 3.3 Local Registries Report Wilfried Woeber, had previously circulated to the list some questions concerning the policy on reallocation of address space in the light of an ACOnet customer who reallocated addresses. This is quite clearly undesirable. Wilfried said that he would put a clear message in the ACOnet application form in an attempt to prevent this, and urged other local registries to do likewise. 4. Charging in 1995 The charging model for 1995 is fixed. It was agreed at the RIPE contributors meeting held on September 21st, 1994. The workplan for 1995 and the expenditure budget of 407,000 ECU were presented at the meeting and both were unanimously accepted. The current status of the budget is that 30% of the planned expenditure has not yet been raised for 1995. During 1995, paying registries will receive a service level above non-paying registries. As from February 1st registries that have committed in writing will get a priority service. To speed up paperwork, the RIPE NCC will accept a committment to pay from a registry as though it is a formal agreement. This is only until February 28th, 1995. There were a number of comments and questions from the audience regarding the financial status of the RIPE NCC and the billing arrangements. Funders were encouraged to use the <billing(a)ripe.net> if they had any queries. There was a question concerning unfair competition from service providers who are not funding the RIPE NCC and therefore do not have the same financial committments. Daniel commented that he cannot determine who is and who is not a service provider, nor who is or who is not a registry. He can only control the service level they receive. 5. Future charging models Daniel Karrenberg reported on the current thinking for future changes to the funding model. The NCC Contributors Committee have discussed and approve a system of usage based charging in 1996. For this to be in place from 1996 onwards, it is vital that the discussions begin soon. Critical decisions need to be made regarding the metrics to be used, the percentage basis of the "usage" based fee. Input is sought from the local registries themselves and the discussion on the local-ir(a)ripe.net mailing list should begin between now and the next RIPE meeting in Rome. Concern was expressed that public bodies and government funded IP services will need to know their expected costs ahead of the financial year. 6. Training Given the overhead that the new registries are now putting on the RIPE NCC, it is clear that is now a need for some registry "induction" or training to take place. It was agreed at the contributors last year in September, that the start up fee would be used to provide some of the resources for this activity. The proposed medium for the training is the WWW. All local registries are asked to provide any material if they have in-house material themselves that is applicable. Action: Mike Norris To send mail to the list asking for input on the content of the training material. It was agreed that the focus of the training would not be "how to be a service provider" but on the functions of a local registry, especially with respect to RIPE interaction. 7. Revision of ripe-104 Very Small Enterprises - VSE's Previously circulated to the mailing list was a document by Daniel Karrenberg describing a proposed method of handling requests from VSE's whose address space assignment utilisation rates are very low. There was no feedback to the document so the discussions have died. Briefly, the document proposed the following : - if no outside connectivity and low host numbers, dont assign unique address space. - when VSE's do connect, ISP's are recommended to use dynamic address space assignment. Wilfried Woeber commented that the ideas presented in the paper sounded sensible, but he was concerned that he lacked a thorough understanding of the technical implications. It was agreed that an "applications document" was needed to accompany this proposal and to circulate the draft of this document to the list. Action: Daniel Karrenberg To draft outline "applciations document" to support the proposed plan on how to deal with address space requests from VSE's Action: Mike Norris To recirculate to the local-ir(a)ripe.net mailing list the document on VSE's as drafted by Daniel Karrenberg. Slow start of registries - Assignment Window In the next revision of this document, there will be a description of the "handholding" procedures and the sliding window mechanism which is now applied to all new registries. Daniel Karrenberg announced that a number of registries, in the past, have assigned excessive amounts of address space to their own organisations. This practice clearly does not follow the procedures for address space assignment and is not in the interests of conserving address space. After some discussion it was agreed that local IR's will themselves have a self-assignment window, with a threshold of either 4 or 8 class C`s which they can assign to themselves without review. Anything higher than this, must be submitted to the RIPE NCC for review. Daniel expressed a preference for a window of 4 class C's. Future of Last Resort Local IR's Last Resort IR's are not currently being charged for RIPE NCC services, because they provide valuable support function to the RIPE NCC. In the future, 2 options present themselves: o last resort IR's charge for their services like any other ISP and multiple ISP's may co-exist. They could be called "provider independant" registries o The distinction between last resort and other registries will disappear as all will be providing a chargeable service. This brings up the issue of the "ownership" of address space. The discussion of portable address space within the IANA is currently very topical. The IANA says that *unless* a contractual arrangement with the customer is made, by the ISP, the customer retains the right to take the address space with them if they change ISP. To try to negate this trend, ISP's could make a charge for out-of-block routing announcements. The customer is faced with the choice of a price/ renumbering trade-off. 8. Revision of European IP network number form (ripe-124) - There was a request that the supporting text for the admin-c: contact person asks that the contact person is available at the site of the network. 9. Global Coordination Daniel Karrenberg reported that both the InterNIC and the AP-NIC procedures with respect to address space assignments are in line with the RIPE NCC. However, the IANA does still make large assignments (which the InterNIC has to carry out). It is felt by all Regional Registries that rfc1466 is in need of revision. On Friday 27th January, 1995, a meeting has been scheduled between all the Regional Registries to discuss and align policies as well as draft a revision of rfc1466. Action: Mike Norris To circulate to the local-ir(a)ripe.net mailing list a summary of the meeting between the Regional Registries. 10. Reverse domains This is reported previously by Geert Jan de Groot under 18.3 11. Tools - Geert Jan reported that 70% of the reverse domain delegation requests contain errors in their set up and are returned to the sender. The French NIC is developing a tool (Christophe Chaillot) which does some error checking. The tool will be distributed once it is finished. - Daniel Karrenberg asked the audience how many people were using the stt tool developed at the RIPE NCC. No-one admitted to using it. 12. Database issues 12.1 RIPE handles Geert Jan gave a short presentation on the use of RIPE handles and how they can be generated using the tool that he has developed. The tool uses finger to find the first free handle in the RIPE database. Action: Geert Jan de Groot: to summarise the RIPE handle tool and to distribute to the local-ir(a)ripe.net mailing list. 12.2 Use of "person" object The use of the person object was clarified. The admin-c: contact should be a person and the tech-c: contact can be a NOC. 13. AOB Billing There is a directory ftp://ftp.ripe.net/ripe/new-registry which contains all the billing relevant documentation. Daniel Karrenberg asked everyone to note that the format of some of the information in this directory has changed recently. Part of the registry database maintained by the RIPE NCC has "billing information". Please note that if you are a member of the EU, you should quote your VAT number otherwise you will be charged +17.5% extra. If you have any doubts about the billing data we hold about your organisation please dont hesitate to check with <billing(a)ripe.net> to ensure that our data is correct and up to date.

1 0

Hardware problems at the NCC
by RIPE NCC Hostmaster 20 Feb '95

20 Feb '95

Dear Local-IR's, As you heard already from Geert Jan we had some hardware problems on friday. It is fixed now and the NCC is working normally again :-) But we might have lost some messages on friday. We tried to restore as much as possible from back up tapes but unfortunately there is a difference betweeen back up and reality ;-) We ask you kindly to resend the whole correspondance you had with us on friday: messages you have sent to us and - if possible - also messages you have received from us on friday. In this way we hope to keep our archives complete and avoid gaps in the communication between you and us. Please include the keyword RESEND in the header of the resent messages. We thank you very much for your understanding and your help and appologise for any inconveniences this may cause. Best regards, RIPE NCC staff

1 0

Hardware problems at the RIPE NCC
by Geert Jan de Groot 19 Feb '95

19 Feb '95

Ticket Number: - Ticket Status: open Ticket Type: unscheduled Ticket Source: RIPE NCC Ticket Scope: RIPE NCC Site/Line: RIPE NCC Ticket Owner: ops(a)ripe.net Problem Fixer: Geert Jan de Groot Ticket Opened: 950217 21:47 UTC Problem Started: 950217 21:00 UTC Closed: Ended: Problem Description: Due to the failure of 2 (two) harddisks at the RIPE NCC on the same day, it seems we may have lost mail sent to the various role accounts on Friday. Also, whois.ripe.net has been offline on Friday for an hour (sorry). Affected: RIPE NCC role accounts: mail which arrived between 950217 00:00 UTC and 950217 22:00 UTC may be lost (we still have the sendmail logs) RIPE auto-dbm updates were deliberately delayed until machines are in full working order, but will be processed shortly. If you have not received an ack by Monday morning, please re-submit the update. We have been unable to send this ticker earlier, because the mail aliases were also on one of the disks involved.. Actions: Install replacement harddisk on whois.ripe.net on Monday (downtime is expected to be < 5 minutes). Restore disk contents of 950217 0:00 (last dump date) for NCC role accounts. Investigate sendmail logs for possible lost mail, and send individual messages, if possible. Restore role account transaction records for 950217 as far as possible. LOCAL-REGISTRIES: if possible, re-send your mail sent on Friday with RESEND in the subject line. Install some garlic in the engine room ;-) While we make dayly backups (of course!), the crash happened 21 hours after the last backup, and those 21 hours includes a full working day. I can't think of a better way to guard against these exceptional circumstances. Time to fix: RIPE NCC operations should be back to normal by the time you read this, but us staff has to determine what mail has been lost. As a result, we might not respond immediately to messages on Monday. I expect to be able to do the harddisk swaps with minimal disruption.

1 0

new expiry date for ripe-124
by Mirjam Kuehne 15 Feb '95

15 Feb '95

Dear Local IR's, As you might have noticed the RIPE document ripe-124 (EUROPEAN IP NETWORK NUMBER APPLICATION FORM & SUPPORTING NOTES) is expired on December, 31st 1994. Unfortunately we had no time yet to revisit it carefully. Since we receive a lot of queries concerning this issue we decided to set the expiry date to 30-June-1995 without changing the document. The document number did not change either! It is still ripe-124. We hope we are able to revisit the document during that time. The document EUROPEAN AUTONOMOUS SYSTEM NUMBER APPLICATION FORM & SUPPORTING NOTES (ripe-109) is expired as well. This document is currently under revision. We hope we can publish it soon. For the time being ripe-109 is valid and can be used. Best regards, Mirjam Kuehne RIPE NCC

1 0

Re: Ticketing
by Geert Jan de Groot 15 Feb '95

15 Feb '95

On Wed, 15 Feb 1995 10:01:49 +0100 Daniel Karrenberg wrote: > Where possible we suggest to include tickets in an RFC822 > header line of the messages concerned. The suggested format > is: > X-NCC-Ticket: NCC#0000 > > Where it is impossible to modify the RFC822 header, this > line can also be included in the body of the message. If > desired the ticket number can also be included in text near > the top of the body of the message. This is easy to do for MH (what we use), but other mailers may have problems with this (I know UCB mail has). Maybe it is better to prepend this in the Subject line, like this: Subject: Request for a class B becomes Subject: NCC#4711 Request for a class B Another advantage is that the ticket automatically gets copied without any effort, while with new headers, 'something' has to be done to copy them in, and as Murphy dictates, it will be forgotten every once a while.. Comments? Should the registry-ID be on the subject line too? Geert Jan

2 1

RIPE NCC Request Tracking and Ticketing
by Daniel Karrenberg 15 Feb '95

15 Feb '95

Deear Colleagues, We hav now reached the point where we have to streamline request processing at the NCC even further. This necessitates the introducion of tickets. I have written up a proposal on how to do things from our point of view which tries to explain *why* we need certain things. I would apreciate feedback from you about this as early as possible. If you have any questions, please do not hesitate to contact me. Regards Daniel Karrenberg RIPE NCC Manager RIPE NCC Request Tracking and Ticketing A Proposal Daniel Karrenberg Manager RIPE NCC February 15th 1995 1. Introduction The RIPE NCC is now processing a substantial amount of requests from local registries as well as individuals. Many of these requests require multiple interactions with the customer (requester) before they can be completed. In addition the NCC has to process requests with different levels of service since February 1st 1995. This situation makes it necessary to formalise request tracking and introduce a ticketing system to keep track of requests. This will improve the speed of processing as well as reduce the resources necessary to establish the context when processing requests. It is hoped it will also improve service to the customer by giving quick and automated infor- mation about the status of a particular request. 2. Registry Identification Each European Local Internet Registry has been assigned a registry Identifier. This ID consists of the two letter ISO3166 country code of the country the registry is esta- blished in followed by a dot and a unique, hopefully descriptive, name for the registry. Registry IDs can be found in ftp://ftp.ripe.net/ripe/registries/, in fact they are identical to the file names in this directory. In order to make an unambiguous link back to the requesting registry and to establish the priority of a request it is necessary that the registry ID is quoted on all messages dealing with requests to the NCC. Where possible we suggest to include it in an RFC822 header line of the messages concerned. The suggested format is: - 2 - X-NCC-RegID: nn.example Where it is impossible to modify the RFC822 header, this line can also be included in the body of the message. Failure to include the registry ID in messages dealing with requests may delay processing as the message may be treated on a "time-permitting" basis if a registry cannot readily be identified. 3. Ticketing The RIPE NCC will assign a unique ticket to each request as it is first received at the NCC. This ticket will be quoted by the NCC on each message to the customer dealing with the request. It should also be quoted by the customer in mes- sages about this request sent to the NCC. The format of the ticket is he string "NCC#", followed by the last two digits of the year the ticket was issued, fol- lowed by a four digit ticket number, e.g. NCC#944711 Tickets should be quoted exactly like this. The letters NCC and the hash sign form an integral part of the ticket. The ticket format is designed with the following criteria in mind: + It has to be syntactically detectable when imbedded in text such as "In reference to tickets NCC#941234 and NCC#946789 we would like to ...". + It has to be easily quotable out of band like "Hey, can you hand me the file about NCC (ninetyfour) twelve thirtyfour please.". + It has to be representable in basic E-Mail and in other means of written communication. Tickets are simply identifiers for a specific request and have no semantic meaning of their own with regard to pro- cessing priority, sequence of receipt at the NCC, resource assignment or anything else. Where possible we suggest to include tickets in an RFC822 - 3 - header line of the messages concerned. The suggested format is: X-NCC-Ticket: NCC#941234 Where it is impossible to modify the RFC822 header, this line can also be included in the body of the message. If desired the ticket number can also be included in text near the top of the body of the message. Failure to include the ticket number in messages concerning ongoing requests will cause additional delays in processing as NCC staff will have to manually identify the ticket con- cerned and add it to the message. Messages received without reference to a ticket may also cause a new ticket to be assigned and later merging to an existing ticket will cause delay. 4. Alternative Embeddings Where it is too cumbersome to include two separate lines for the registry ID and the ticket in a message, the information can be combined on a single line like this: X-NCC-Request: nn.example NCC#941234 5. Self Ticketing For registries who keep their own tickets on requests the NCC is willing to consider to allow self ticketing of requests. We would suggest to use a format consisting of the registry ID, a hash sign and a number, e.g. nn.example#123456 but we are flexible w.r.t. the ticket format as long as it is unique and satisfies the criteria mentioned above. If the need arises we will also investigate methods to cross reference ticket numbers of different systems as necessary. This may mean that we will have to carry multiple tickets for each request. The above suggestion is intended to minimise the need for that. Please contact the NCC if you would like to use self ticket- ing.

1 0

local hostcounts
by Mirjam Kuehne 15 Feb '95

15 Feb '95

Dear Local IR's, As suggested during the last RIPE Meeting in Amsterdam I want to encourage you to do your hostcount locally. The advantage is that the data is more up to date. It lowers the traffic and transmission errors. Till now the following countries count their hosts locally: ie, uk, de, gr, cy, at, pt Next month fr will join. The only things you need to do are: 1. to run host (available as ftp://ftp.ripe.net/tools/dns/host.tar.Z) 2. to run a shell script like: #!/bin/sh host -lav -s 10 -L 999 pt. > pt.output 2> pt.error 3. to make these two files gzipped available somewhere for me to pick it up. I hope this will encourage you to count your hosts locally. If you have any further questions don't hesitate to contact me. Best regards, Mirjam RIPE NCC

1 0