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

Re: Modifying references to contact info in the RIPE DB
by Wilfried Woeber, UniVie/ACOnet 24 Jun '01

24 Jun '01

Hi Joao! >If the reference is by name then when I query the DB I will get the list of >persons with that name, right? Right. >Whether the object belongs to the person or not is not going to save this >person from being contacted. From the point of view of the database and the >user querying it, the object belongs to that person. Right >The link is via a name. > >Now we substitute the reference by name with a reference by nic handle >pointing to the same person. >What is the difference? > >ALMOST NONE except that: True, for the case where there is a strict one-to-one mapping, e.g the recursion using the name returns *one* object. What do you suggets to do with the case where the recursion, based on the names, returns a *set* of objects? I can see 2 approaches (at least): - do not perform the handle substitution for that referring object and put it on the list of those requiring human intervention - expand the xxxx-c: list (which? the tech-c:?) to refer to *all* objects, but by ref'ing their handles While human beings are quite clever in selecting the "proper" instance of a person: object (by looking at country, address, email,...) a script might be quite clueless with that respect :-) 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 (&NIC) Handle: WW144 A-1010 Vienna, Austria, Europe : PGP public key ID 0xF0ACB369 --------------------------------------------------------------------------

3 3

RE: DB consistancy checking tools
by Matthew Robinson 07 Mar '00

07 Mar '00

I won't be at RIPE-35 as my first child is due at the same time but I'll definitely knock something together as a draft. If other people are interested then things should go ahead at RIPE-35 otherwise I do have permission from my wife to attend RIPE-36 ;-) Kind regards Matthew -----Original Message----- From: Wilfried Woeber, UniVie/ACOnet [mailto:woeber@cc.univie.ac.at] Sent: 20 January 2000 14:55 To: matthew(a)planet.net.uk Cc: lir-wg(a)ripe.net; db-wg(a)ripe.net; woeber(a)cc.univie.ac.at Subject: RE: DB consistancy checking tools Matthew, I think this is an interesting proposal: >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 To start things moving, could you come up with a coarse draft of ideas and short-term goals to take up? On the more formal side, one of the possible solutions to accomodate that activity might be to create a TaskForce to work on well-defined items during RIPE35 (do you intend to particpate?). This TF might be supported by both LIR and DB, or sponsored by whichever group is seen to be appropriate... Wilfried.

6 6

LIR.34.6 Define final Address council selection procedure
by hph＠infostream.no 27 Jan '00

27 Jan '00

Dear Local IR WG & RIPE community at large, At the last RIPE meeting we selected 3 representatives to the ICANN ASO address council by an interim mechanism that was defined at the meeting. This was indeed an interim solution and we need to agree on a more formal method before the first term of an AC member expires. The selection procedure itself must be open and transparent. By extension, the process by which this procedure is defined should also be open and transparent. In this sense, the whole RIPE community should be involved. The correct forum is, I believe, the LIR WG, but it is worth broadening the participation to allow anyone to take part in the discussion on the list and at RIPE meetings. This matter will be one of the most important discussions at the upcoming RIPE 35 an I will urge you all to contribute, both to the mailinglist and at the meeting. The discussions will take place in the lir-wg or in a separate meeting for this topic only, if the meeting schedule permits The framework these selections must operate within is by the ASO MoU and, ultimately, by the ICANN bylaws. http://www.aso.icann.org/docs/aso-mou.html The most relevant points being: 2a Selection. Each RIR signatory of the MOU will select three [3] individuals to the Address Council using the following process: (i) Each RIR will annually issue a public call for nominees to the Address Council at least 90 days before the RIR's policy meeting. Any individual can submit a nomination to the RIR. (ii) The due date for this call shall be 30 days before the meeting. (iii) The nominees must be individuals. (iv) A list of all nominees who agree to run for the Address Council must be posted on the RIR's web page at least 15 days before the meeting along with a statement from each nominee who wishes to make one. (v) Selection of the RIR's members of the Address Council will be made via an open and transparent procedure. The individuals selected for the Address Council must not be staff members of any RIR. (b) Term. The term of Address Council members will be 3 years. The initial Address Council members selected within each region will have staggered terms of 1, 2 and 3 years. The process by which these initial members are selected must also determine in an open and transparent manner, the assignment of terms to each of the initial members. --- So if the next selection is to be performed at RIPE 37 in September the open call needs to be before June, or practically best at RIPE 36 in Budapest. We should best case define the selection procedure at RIPE 35 but it could be concluded at RIPE 36 at latest. Since the MOU describes the nomination process in broad terms and not to specific details like whether the nominations should be done publicly or not, and whether one should have the opportunity to express support to individual candidates or not. This may need to be refined. In particular we need to address - Can an individual nominate themselves? - Does the nomination need to come from more than one person? To the selection procedure in particular at least the following needs to be defined: - Who performs the selection - In what way is the selection performed We should bear in mind that the process should be open and transparent, and it is likely to be some sort of election but that is not strictly necessary. - We need to consider whether to do the election at a meeting - or electronically I would like to see a small task force formed that will summarise the discussion on the mailinglist into at least one proposal to be presented at the next RIPE meeting. Tentative plan: 18/1 Start of discussion 31/1 End of discussion 7/2 Proposal circulated on list 21/2 Week of RIPE 35 Sincerely, Hans Petter Holen LIR-WG chair

4 3

LIR-34.4 Form a task force for documenting the existing policy process
by Hans Petter Holen 25 Jan '00

25 Jan '00

Moving further forward on the action list I would like to initiate this small project: produce documentation on how we develop addressing policy in the RIPE region. Tentative plan: 11/1 Kick off 24/1 Close of discussion on list 31/1 Editorial group posts draft to the list 21/2 Week of RIPE 35 thus aggressive, this plan does provide some slack to ensure deliverables before the RIPE meeting. Note that the task this time is to document the current process, not suggest a new better or improved process. I believe it is important for everybody involved, or remotely interested in, how addressing policy in the RIPE is developed to have a common understanding on how the current process works BEFORE we start discussing how to improve the process if at all needed. Background. ========== The RIPE working group named lir-wg, and abbreviation for Local Internet Registry Working Group, is the open forum where addressing policy in the RIPE area as been developed. Great care has been taken by the community, the previous chair of this working group , and the chair of RIPE in particular, to keep this an open forum. It is worth being particularly clear on the fact that, even though the RIPE NCC finances and operations are eventually controlled by the RIPE NCC Association membership, i.e. those who buy services from the RIPE NCC, particular care has been taken over time to make sure that the forum for setting the addressing policies RIPE NCC operates under, is NOT restricted to its membership. Historicaly we have initiated changes to policy in several different ways: - Changes have been initiated from the RIPE NCC - Individuals have initiated Changes - Other fora like IETF have initiated Changes Developing documentation of new policy has likewise been carried out in a number of slightly different ways, the two most important being: - The major rewrite that resulted in RIPE 185 European Internet Registry Policies and Procedures was managed by an editorial group consisting on members of the working group and RIPE NCC staff. The policy was put in writing by the RIPE NCC staff acting as a secretary of the group. - The IPv6 policy document RIPE 196 was developed jointly by the regional registries in close co-operation with the IP v6 working group. The working groups conduct their work not only at open meetings at the open RIPE meetings where anybody can Common to all of this is that the final policy documents are made public not only to the working group but also presented to the RIPE plenary and published on the RIPE public web site at www.ripe.net. Currently there are no formal ways to adapt new policy at the working groups meeting or at the mailing list. This leaves the chair of the WG with the particular power to suggest to the meeting not to adapt changes and thus initiate further discussion at the list or future meetings. The meeting does have the power to follow such advice or not. In many ways this is similar to the IETF rough consensus, but we need to rely on advice from the RIPE NCC, our common sense and fairness instead of running code. The following people volunteered at the meeting to form a task force to write up this: Aaron Hamilton - Cable & Wireless Sam Critchley - UUNET Tim Dmons - IS Products, UK Barbara Roseman - Frontier globalcenter Hans van der Veer, Lucent tech Gordon Lennox, European Commision Could you reconfirm your availability within the suggested timeframe and interest to me personally and provide me with your preferred email address. Other volunteers are also appreciated! Sincerely, Hans Petter Holen

1 2

Re: minutes
by Wilfried Woeber, UniVie/ACOnet 24 Jan '00

24 Jan '00

According to Hamid Alipour: >The thing that I would like you consider is that we have enough address >space availble trough IPv6. I have two remarks here: >1- why should IPv6 address space alocation follow the same procedure as > IPv4 Well, it's not the same procedure ;-) There is a different (if administratively similar!) set of guidelines and procedures in place for obtaining an sTLA to enable an Internet Service Provider to design and build an IPv6-based service. It has taken of lot of effort and discussion to propose, refine, review and finally agree, on the current set of guidelines. There is a lot of documents out there (RFCs, drafts, allocation guidelines) documenting the current lines of thinking. Of course, as the Internet evolves, there's going to be a constant need for review, refinement and - probably - changes. > while we had address space limitation there and we do not have > address space limitation in IPv6 then we must ease address space > allocation in IPv6. I think you should consider the fact that an IP-Address in *itself* (be that v4 or v6) is only of limited use. In most cases, it only becomes a valuable resource as soon as a set of addresses (a "prefix") gets configured in a real network and announced on the routing layer. > currently I have to run a procedure for each end > user who whishes to get address space Having gone through the procedure with RIPE to acquire an sTLA, I'm not able to remember that requirement?! > and I have ensure RIPE that the > address space is really needed.end users do not have this permistion to > reserve address space. Let's assume for a minute that there is no feedback loop in place which requires "you", or anyone else, to document your need - how much of the "vast" IPv6 address space would you want to reserve for your <"insert your organisation here">? One quarter? Only 20%? What would be a "fair" percentage for your <"organisation">? > that's ok while we are dealing with IPv4 , but > what about IPv6? all of us know that designing a network with larger > address space is easier and we can consider further developments too, > address space is not fragmented and the network can run with higher > performance. routers will have smaller routing tables and we can save > RAM and CPU resources.due to limited address space in IPv4 it was not > possible. optimizations was based on minimizing required address space > , with IPv6 we can optimize the network design based on less resource > usage and higher performance. > >2- make address space allocation in IPv6 Localized. > we can allocate some prefixes for countries , say put aside 2 bytes of > address space. no? put aside 3 bytes, more or less put some space for > countries. in 2 byte version we would have 65536 country codes while > we do not have such amount of countries.RIRs can assign some prefix > to companies which act international.let say a company whishes to act > nation wide after a while he decides to have an office in an other country. > he must register his office in that country and get some permission for > his activities there, let they get an address space assignment from LIR in > that country besides other permissions they have to get.they can do this > or negotiate with a IR to get a multi-national or international prefix. > how much effort is needed for this? and compare it with this procedure > that I have to negotiate and get approval from RIPE whenever an ISP > in my country needs address space. I think we have been through that one more than once, and I do not see any reason why the answer for IPv6 could be fundamentally different from the answer for IPv4. 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

Re: minutes
by Hamid Alipour 22 Jan '00

22 Jan '00

Hi, this may be a dump question , but does any body care to say that why RIRs or IANA itself should have this responsibility to IPv6 address space allocation? well, I know there has been a problem regarding IPv4 and that was limited address space which was available using IPv4.with IPv6 we do not have such problem then why should the things go on exactly as it was in IPv4? as Telecom engineer I know that the things is so easy when I am going to design a numbering/routing plan for telephony services. prefix "98 " is allocated to my country and deciding about the rest of number space (address space) is my business I am not going to get approval from ITU to allocate 98 31 to Isfehan for example, it is not ITU's business to care about the numbers that is assigned to end users in Iran. and I am not asked to report the address space consumption status to ITU. why shouldn't the things go on exactly the same while we have enough address space in IPv6? It is said that we would have enough address space to allocate to people who may live in moon or mars! let's leave it for future and just allocate address space for countries and end the allocation story there , address space is a resource just like frequency band width in US it FCC who should care about this and in Iran , PTT will decide how to use this resource. Best Regards Hamid Alipour ----- Original Message ----- From: David Kessens <david(a)qip.Qwest.net> To: <ipv6-wg(a)ripe.net> Cc: <meeting(a)ripe.net> Sent: Friday, January 21, 2000 8:27 AM Subject: minutes > > Hi, > > Please see below for the minutes of our last session. > > I would like to thank Petra Zeidler for taking and preparing the > minutes. > > I would like to declare them the final version if I don't receive any > major comments until January 31. > > Thanks, > > David K. > PS I will not be very responsive for the next weeks due to a vacation > --- > > Slides available from http://whois.6bone.net/~david/presentations/ > > Minutes of the IPv6 WG meeting at RIPE 34 > > Agenda: > > A. Administrative Stuff > Scribe is Petra Zeidler > Agenda got reshuffled, beside that no changes > > > B. Status of 6BONE (David Kessens) > see slides for the contents of the presentation > no Questions > > > C. Experience from the RIPE NCC with IPv6 allocations (Mirjam Kuehne) > http://www.ripe.net/meetings/ripe/ripe-34/pres/ipv6-alloc-experience/index.h tml > Questions: > - Does RIPE NCC look at IPv4 allocations when deciding about IPv6 > alloc.? - no, one can start out with IPv6 address space > - How long does getting an allocation take? - about as long as a large > IPv4 assignement now, but in the beginning it took longer due to > necessary shakedown of procedures > - What about the "exchange points distribute address space" point? - > Neither the exchanges nor the registries are particularily keen to see > that, maybe clear that up in the documentation > - is the problem of how to handle different address spaces at the > client site, their upstream and the exchange point worked out? - no. > Input from the Exchange people needed, the IX wg is in parallel to > this meeting > - how does one find IPv6 database objects in the database? - by using > whois, the object types are inet6num and ipv6site > > > D. Experience from APNIC with IPv6 allocations (Fabrina Hossain) > http://www.ripe.net/meetings/ripe/ripe-34/pres/apnic-ipv6/index.html > Questions: > - what is a NIR, and what's the IPv6 problem with them? - a national > internet registry, an intermediary between RIR and LIR; assigning a > block of STLAs is not planned in the current regulations, but would be > sensible. This point needs to be cleared up yet. > - are there political problems with or for NIRs? - none up to date > - what type of IPv6 usage happens in the APNIC region? - tunneled over > IPv4 > > > E. Experience from customers of the RIPE NCC with IPv6 allocations (audience) > Stephen Burley, UUnet UK: > requested at 3 registries due to their international character, got > /35. Issues are Aggregation and looking at a whole continent > /29 is reserved for them so they can expand contiguously > UUnet is still staring up IPv6 operations, they have renumbered from > their 6bone addresses and had questions from customers about IPv6, but > did no assignments yet. > general point: > what about company mergers and splits? - renumbering is easy in theory > Wilfried Woeber for Vienna Uni, RIPE IPv6 allocation #6: > IPv6 requires quite different architecture considerations regarding > wether to assign a /64 or a /48 > actually using IPv6 found surprising, non-obvious traps (eg DNS) > working with RIPE to get the allocation was nice > planning for IPv6 is hard to do due to lack of experience on all sides > the role of IXes is unclear. Are they to move from being a switch to > being a router? How does one build infrastructure for a routed IX? > What about the IPv6 multihoming issue? For an IXes own routing > infrastructure there are no address issues > > > F. IPv6 forum creation (David Kessens) > there has been a mailinglist created ~2-3 months ago with subject > deployment of IPv6. It contains technical questions & answers > There's a website too, http://www.ipv6.org/ > It is meant to be a formal organisation to promote IPv6 > It currently has 55 members, the membership fee is ~$2500 a year) > The IPv6 forum sponsors meetings to spread information about IPv6 > It has two main goals: inform and help in deployment by collecting > useful information > next meeting will be in October near Paris named "Global IPv6 summit" > on the 8/9 dec there will be a meeting in Berlin to be help in German > language, but translations will be offered too > a meeting in Japan is planned, but there's no date yet > > > H. IPv6 test project done by TF-TANT > (Simon Nybroe, http://www.tbit.dk/quantum/slides/ripe34qtpv6/index.htm) > Questions/comments: > DNS still needs IPv4 connectivity to be able to do its "tree walk" > There are more applications needed that work with IPv6 > A IPv6 routing registry needs to be considered > > > G. European developments/initiatives regarding IPv6 > - there's a project to link 6TAP and AMS-IX using a native IPv6 link > AMS-IX has IPv6 on the Ethernet and at 6TAP it's available over the > peering router. > Question: is it an experiment or are there plans to offer "ordinary" > transit? - no transit yet, currently it will run in a ~3month test > period > > > X. Any Other Business > - there's IPv6 in the RIPE terminal room, with www.ipv6.surfnet.nl as > tunnel router > - IPv6 policies are to be dicussed in the LIR WG, only implementation > matters at IPv6 WG, as IPv6 is now in assignment production. > Anyone may take part in the LIR WG (only the LIRs really ought to :-) > > > -- >

3 5

RE: DB consistancy checking tools
by Wilfried Woeber, UniVie/ACOnet 20 Jan '00

20 Jan '00

Matthew, I think this is an interesting proposal: >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 To start things moving, could you come up with a coarse draft of ideas and short-term goals to take up? On the more formal side, one of the possible solutions to accomodate that activity might be to create a TaskForce to work on well-defined items during RIPE35 (do you intend to particpate?). This TF might be supported by both LIR and DB, or sponsored by whichever group is seen to be appropriate... 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

RE: DB consistancy checking tools
by Wilfried Woeber, UniVie/ACOnet 20 Jan '00

20 Jan '00

With reference to: >From: stephenb(a)uk.uu.net >Date: Tue, 11 Jan 2000 11:49:34 +0000 (GMT) >Subject: DB consistancy checking tools >To: lir-wg(a)ripe.net > >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 I've got one tech Q and one org Q: Tech: Would you want to propose a "public release" of the tool (e.g. to be able to deploy it in a local environment), or would it be useful / sufficient to be able to trigger the tool (for a given address range) and to have access to the result? I'm aware of the fact that there might be access and/or security related issues requiring a solution, but we might be able to solve that as soon as we know what to look for.... Org.: Where is this to go? LIR or DB? Preferences? ( In general I prefer a path where the goals and application requirements emerge from an "application WG" and the implementation is then passed on to the DB-WG. ) Wilfried.

1 0

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