- lir-wg - mailman.ripe.net

RE: DB consistancy checking tools
by Matthew Robinson 20 Jan '00

20 Jan '00

I have been wondering recently whether a separate group should be set up for the sole purpose of creating tools/advise/methods/hints 'n' tips for LIR's to keep on top of their entries and make management easier. A sort of RIPE users working group not concerned with designing objects for the database but how to put existing objects in it, remove them, manage them, etc. My 2c Matthew -----Original Message----- From: Wilfried Woeber, UniVie/ACOnet [mailto:woeber@cc.univie.ac.at] Sent: 20 January 2000 13:07 To: stephenb(a)uk.uu.net Cc: lir-wg(a)ripe.net; woeber(a)cc.univie.ac.at; db-wg(a)ripe.net Subject: RE: DB consistancy checking tools

1 0

Top 100 Maintainers List 20000119
by RIPE Database Administration 19 Jan '00

19 Jan '00

1 0

RIPE hostmasters visiting LIRs
by Sam Critchley 19 Jan '00

19 Jan '00

Hello, Last time I brought this subject up I had some very positive response from people on the lir-wg mailing-list, and some concerns as to whether it would ever be possible to put into practice what seems like a good idea in theory. If people are willing to read/listen I would like to raise the subject once more, as I think it may be possible to work through some of the issues raised. What was proposed was some kind of scheme whereby RIPE hostmasters are able to visit some of the LIRs that they deal with. The idea was that this would benefit the RIPE community at large by keeping hostmasters in touch with practical matters in the LIR world (and therefore, in most cases, the world of commercial IP). Once gained, this greater understanding would allow hostmasters to further improve their work in dealing with these, and other, LIRs, thus being of benefit to the community at large. One of the issues addressed in the original mail was that of neutrality - if such a scheme were to be organised then it would have to be designed in such a way that there were no neutrality implications for the NCC or LIR. This would mean that the process by which participant LIRs were selected would have to be such that it was agreed that no LIRs or set of LIRs were shown favour in any manner whatsoever. With this in mind I'd like to raise (and generate some discussion on) some points, perhaps with a view to coming up with an outline which could acceptably be put into practice: 1. Selection of participating LIRs. I think some people got the impression that this would be a scheme to visit all LIRs - I really don't think this would be workable unless given a very large amount of money from member contributions or unless paid for by individual LIRs. So, how about keeping the number of visits to a very small selection of LIRs? You are then faced with the problem of how to select them - obviously this is very open to discussion, but one method might be: a) The RIPE NCC divides all LIR membership into operational area and into registry size, then picks LIRs at random from within these divisions. b) The NCC then approaches these LIRs to ask whether they would be interested in participating (assuming certain conditions of participation). Should they wish to be visited, this is arranged. Should they not wish this to happen, then the NCC picks another LIR from the same region/size grouping. c) The visit occurs - if appropriate, then hostmasters with language skills suitable to the LIR's operational area make the final arrangements and pay the visit. 2. Financing. A point was raised before by Jan Czmok of Gigabell and added to by Amar from Telia about financing - they came up with some suggestions on a financing structure. One of the points made was that, should this lead to an increase in registry fee, then it would not be popular. I think it would be possible to visit a small number of LIRs (as suggested above) without needing any extra contribution. The main point here is that enough LIRs are visited so that hostmasters gain experience to help them with their job, and not that all LIRs are visited. Obviously, there would be a need to work out projected costs and see if this fits in the existing budget. 3. "Lobbying". It should be made clear to participating LIRs that under no circumstances would a visit from RIPE NCC hostmasters provide any opportunity for an LIR to express any "political" views about their relationship with the RIPE NCC or the community in general, and that no behaviour should take place which could compromise the neutrality of the RIPE NCC and its representatives towards all RIPE members. Examples of such behaviour might be (?): - too much reference to any problematic issues which have occurred previously in that LIR's relationship with the RIPE NCC or with other LIRs. - any attempt to gain "extra" service compared to other LIRs in the RIPE community. In this case I believe that the RIPE NCC should cover any hotel and transport costs as part of the budget for a visit such as this, but that provisioning of drinks and meals such as lunch and some evening entertainment would be acceptable. What do other mailing-list recipients feel? I think untoward behaviour would be unlikely to happen as most LIRs in the RIPE region are very aware of how solid the impartiality of the NCC staff is, and would be unlikely even to attempt to affect this. 4. Inspection/Audit. There was a suggestion earlier that this kind of visit be used to help those LIRs experiencing problems with consistency. I don't believe that this would be appropriate, and that to do this would be to move away from the aim of the project - to benefit the entire community by allowing individual hostmasters to become more familiar with the way RIPE members operate. I think it would be a good idea to stress that any experience gained would be under an informal (or formal if required) non-disclosure setup, and that even should hostmasters witness the worst kind of IP practice in an LIR, there should be no consequence for the relationship between LIR and NCC, nor would any record be kept of the nature of these practices. I'd like to try and move this forward in discussion - I still think it's quite possible to get some kind of limited visiting scheme up and running, provided other members and the NCC agree on the structure, and I feel it would be of benefit to everyone if properly structured. I would welcome all comment on this list both from LIRs and representatives of the NCC. Apologies for the long mail!! Best wishes, Sam ******************** samc(a)uu.net Tel: +31 20 711 6082 ********************

1 0

LIR-WG Action LIR-34.8 - Additional values for the inetnum status field
by James Aldridge 14 Jan '00

14 Jan '00

Better late than never, here is a slightly modified version of my proposal (originally posted before RIPE 34) for an additional value for the status field in an inetnum object (specifically "status: LIR-ALLOCATED"). James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- - ----- Tel: +31 20 530 5327; Fax: +31 20 622 4657 ---------- cut here ---------- "Status: LIR-ALLOCATED" Considered Useful For various reasons large registries often need to distribute their allocated address space between various parts of their organisation (for example we have separate national operations in 20 or so countries obtaining address space through the eu.eunet registry). In these situations it makes sense to document this redistribution in the RIPE database but there is currently no way to do this without throwing up errors in the RIPE NCC's auditing procedures or by removing flexibility and adding more work to the already busy NCC hostmasters by having each local operation treated as having their own allocation. Previously the RIPE database software allowed anyone to register an object with a status value of "ALLOCATED" but this was abused by people who didn't know what they were doing and so this is no longer possible and all non-NCC registered inetnum objects must now have the status of "ASSIGNED". However, having multiple levels of assignments in the RIPE database causes error reports from the NCC's auditing processes which now see anything under the higher- lever sub-allocation as being a duplicate (or overlapping) assignment which makes finding "real" problem assignments difficult or impossible. By allowing a local IR to register an inetnum object with a new status value of "LIR-ALLOCATED" it becomes possible to differentiate between a higher level sub-allocation ("status: LIR-ALLOCATED") and a final assignment by a LIR ("status: ASSIGNED"). By allowing this registration of intermediate objects it would also be possible to restrict changes to lower-level objects differently in different blocks of addresses within the LIR's allocation by setting different "mnt-lower" values without having to open the whole allocated block up for changes by anyone who might have a valid reason for updating a particular (range of) inetnum object(s). An example may help to explain things at this point: inetnum: 10.1.0.0 - 10.1.255.255 netname: ZZ-REGY-19990916 descr: REGY Allocation country: EU ... status: ALLOCATED PA mnt-by: RIPE-NCC-HM-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.31.255 netname: ZZZ-REGY-ALLOC descr: REGY - Local assignments in ZZZ country: ZZ ... status: LIR-ALLOCATED PA mnt-by: EUNET-MNT mnt-lower: EUNETZZ-MNT ... source: RIPE inetnum: 10.1.0.0 - 10.1.0.63 netname: CUSTOMER-XYZ-NET descr: Customer XYZ in ZZZ country: ZZ ... status: ASSIGNED PA mnt-by: EUNETZZ-MNT ... source: RIPE Here the first inetnum object refers to the top-level allocation made to a local IR by the RIPE NCC and has the normal RIPE-NCC-HM-MNT maintainer field which restricts changes to the RIPE NCC Hostmasters only. The second inetnum object is registered by the central administrator of the local IR and the normal maintainer object for that administrator - EUNET-MNT in this case. There is also a mnt-lower field permitting the national administrator to whom this sub-block is "allocated" to register end-user assignments. The last inetnum object here is a final assignment from the national organisation to a customer.

1 0

Re: LIR 34.11 Discuss moving IPv6 policy matters to lir-wg
by Wilfried Woeber, UniVie/ACOnet 12 Jan '00

12 Jan '00

Hi Hans Petter! >I would like to ask the lir-wg and the ipv6-wg to give its opinions on this >matter, and if possible to conclude. > >Conclusions could be: >1) Keep it as is >2) Move all policy discussions to lir-wg >3) Keep it as is for next n meetings My feeling is that the time has come to move IPv6 addressing policy and address distribution items to the LIR-WG, thus I'm proposing "option 2". I think it was indeed appropriate to take care of IPv6-specific issues in the framework of the IPv6-WG, in particular as long as we are/were living in a test-bed kind of environment. (Btw, 6Bone issues, as well as technical issues should still remain with the IPv6 WG) However, as LIRs now can request IPv6 address space *for production use* in much the same way as IPv4 addresses, there's not too much "special handling" requirements left, I suppose. Wilfried. -------------------------------------------------------------------------- Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Vienna University : Fax: +43 1 4277 - 9 140 Universitaetsstrasse 7 : RIPE-DB Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 __________________________________________________________________________

1 0

LIR 34.11 Discuss moving IPv6 policy matters to lir-wg
by hph＠infostream.no 11 Jan '00

11 Jan '00

At the two last lir-wg meetings ar RIPE meetings the question of wether IPv6 policy matters should be discussed in a separate working group or in the lir-wg where all other policy matters are discussed has been brough up. Two meetings ago I rejected this suggestions for two reasons: - I did'n feel qualified to chair the rather detailed technical discussions going on related to the v6 policies - The lir-wg agenda was filled with other matters The reasons for suggesting moving the discussions to the policy forum is to keep policy discussions in one place, thus making schedulig simpler for policy interested meeting attendants. I would like to ask the lir-wg and the ipv6-wg to give its opinions on this matter, and if possible to conclude. Conclusions could be: 1) Keep it as is 2) Move all policy discussions to lir-wg 3) Keep it as is for next n meetings Yours, the lir-wg chair.

1 0

LIR-34.1 Suggest clarification of WG charter
by Hans Petter Holen 11 Jan '00

11 Jan '00

It is time to get moving on the Action list: http://www.ripe.net/ripe/wg/lir/lir-actions.html The web site now reads: Charter The Local IR working group - the open forum where RIPE policy is made - deals with issues that concern Local Internet Registries. For example, Local IR operation, and the local implementation of RIPE policies and procedures are discussed in this working group. as a syntesis of the old description and my openness slogan from RIPE 34. I would ask the working group to adapt this charter or even better suggest improvements to it. Yours, the Chair.

1 0

Re: New RIPE NCC Website
by Hans Petter Holen 11 Jan '00

11 Jan '00

Congratulations to the RIPE NCC staff for a new and improved web site ! I would in particular draw your attention to the lir working group pages at http://www.ripe.net/ripe/wg/lir/index.html Sincerley, Hans Petter Holen WG Chair. ----- Original Message ----- From: "RIPE NCC Staff" <ncc(a)ripe.net> To: "Local Internet Registries in Europe" <local-ir(a)ripe.net>; "Reseaux IP Europeens" <ripe-list(a)ripe.net> Sent: Monday, January 10, 2000 6:56 PM Subject: New RIPE NCC Website > > > Dear Colleagues, > > The RIPE NCC is happy to announce the launch of its re-structured > Website. > > The aim was to provide users of the site with more structure and ease > of use without eliminating the clarity of the pages which have > received recognition in the past. > > With the new structure in place, we hope that you will find it > easy to navigate through the site and find all of the information > you require. The site also marks the launch of the new RIPE NCC > logo. > > A special thanks to all who have provided input to the new site. > > Naturally, any errors can be reported to <webmaster(a)ripe.net>. > > Regards, > > Paul Rendek > Communications Officer >

1 0

DB consistancy checking tools
by stephenb＠uk.uu.net 11 Jan '00

11 Jan '00

Hi After making a number of NEWBLOCK requests and recieving the information back of the errors in the DB for the previous block, i would like to make the suggestion to the RIPE NCC the we are allowed accuess to this most useful tool. This way we could do the consitancy checks and get our house in order before making the NEWBLOCK request, lessening the load on RIPE and speeding up the allocation of more CIDR. If there is enough interest can we add this as a point of discussion at the LIR working group, or should it be in the DB group. BTW i do like the new web site. Regards, -- ---------------------------------- E-Mail: stephenb(a)uk.uu.net Phone: +44 (0)1223 581051 Stephen Burley EMEA Registrar UUNET ----------------------------------

1 0

Top 100 Maintainers List 20000103
by RIPE Database Administration 04 Jan '00

04 Jan '00

1 0