From ripe-dbm at ripe.net Tue Jan 4 03:27:13 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Tue, 04 Jan 2000 03:27:13 +0100 Subject: Top 100 Maintainers List 20000103 Message-ID: <200001040227.DAA00373@birch.ripe.net> Dear list members, This is biweekly report on inconsistent objects in the RIPE whois database. The first 100 maintainers are listed as a table below sorted according to number of their inconsistent objects in the database. The rest of the maintainers which have inconsistent objects can be found at http://www.ripe.net/db/state/mntnerreport1.html You can find further information about the Consistency Project at http://www.ripe.net/db/state/ Regards, RIPE NCC Database Group =============================================================== Maintainer no of name inconsistent objects 1 XLINK-MNT 45500 http://www.ripe.net/db/state/maintainers/XLINK-MNT.html 2 DENIC-P 42530 http://www.ripe.net/db/state/maintainers/DENIC-P.html 3 DK-DOMREG 8807 http://www.ripe.net/db/state/maintainers/DK-DOMREG.html 4 ROKA-P 3331 http://www.ripe.net/db/state/maintainers/ROKA-P.html 5 DTAG-NIC 3229 http://www.ripe.net/db/state/maintainers/DTAG-NIC.html 6 SCHLUND-P 2421 http://www.ripe.net/db/state/maintainers/SCHLUND-P.html 7 FR-NIC-MNT 2127 http://www.ripe.net/db/state/maintainers/FR-NIC-MNT.html 8 BO-DOMREG 1641 http://www.ripe.net/db/state/maintainers/BO-DOMREG.html 9 ECCE-NOC 1637 http://www.ripe.net/db/state/maintainers/ECCE-NOC.html 10 DREIMARK49-MNT 1589 http://www.ripe.net/db/state/maintainers/DREIMARK49-MNT.html 11 NACAMAR-NOC 1563 http://www.ripe.net/db/state/maintainers/NACAMAR-NOC.html 12 WWW-MNT 1435 http://www.ripe.net/db/state/maintainers/WWW-MNT.html 13 ABCAG-MNT 1339 http://www.ripe.net/db/state/maintainers/ABCAG-MNT.html 14 DENIC-N 1042 http://www.ripe.net/db/state/maintainers/DENIC-N.html 15 AS1849-MNT 812 http://www.ripe.net/db/state/maintainers/AS1849-MNT.html 16 HIGHSPEED-DOM 759 http://www.ripe.net/db/state/maintainers/HIGHSPEED-DOM.html 17 ECORE-NET 729 http://www.ripe.net/db/state/maintainers/ECORE-NET.html 18 INTERNET-NOC 697 http://www.ripe.net/db/state/maintainers/INTERNET-NOC.html 19 SEKTORNET-MNT 573 http://www.ripe.net/db/state/maintainers/SEKTORNET-MNT.html 20 CSL-MNT 569 http://www.ripe.net/db/state/maintainers/CSL-MNT.html 21 DKNET-MNT 558 http://www.ripe.net/db/state/maintainers/DKNET-MNT.html 22 DFN-NTFY 548 http://www.ripe.net/db/state/maintainers/DFN-NTFY.html 23 NACAMAR-RES 494 http://www.ripe.net/db/state/maintainers/NACAMAR-RES.html 24 DE-VOSS 489 http://www.ripe.net/db/state/maintainers/DE-VOSS.html 25 GLOBAL-MNT 428 http://www.ripe.net/db/state/maintainers/GLOBAL-MNT.html 26 SDT-NOC 423 http://www.ripe.net/db/state/maintainers/SDT-NOC.html 27 TDK-MNT 418 http://www.ripe.net/db/state/maintainers/TDK-MNT.html 28 OLEANE-NOC 381 http://www.ripe.net/db/state/maintainers/OLEANE-NOC.html 29 DIGITALWEB-MNT 374 http://www.ripe.net/db/state/maintainers/DIGITALWEB-MNT.html 30 KNIPP-NOC-MNT 364 http://www.ripe.net/db/state/maintainers/KNIPP-NOC-MNT.html 31 NACAMAR-POP 358 http://www.ripe.net/db/state/maintainers/NACAMAR-POP.html 32 IDNET-MNT 356 http://www.ripe.net/db/state/maintainers/IDNET-MNT.html 33 RAIN-TRANSPAC 350 http://www.ripe.net/db/state/maintainers/RAIN-TRANSPAC.html 34 RAK-NET 348 http://www.ripe.net/db/state/maintainers/RAK-NET.html 35 WESPE-MNT 347 http://www.ripe.net/db/state/maintainers/WESPE-MNT.html 36 MARIDAN-P 335 http://www.ripe.net/db/state/maintainers/MARIDAN-P.html 37 AS6678-MNT 323 http://www.ripe.net/db/state/maintainers/AS6678-MNT.html 38 FR-EASYNET 321 http://www.ripe.net/db/state/maintainers/FR-EASYNET.html 39 INX-MNT 320 http://www.ripe.net/db/state/maintainers/INX-MNT.html 40 IL-P 317 http://www.ripe.net/db/state/maintainers/IL-P.html 41 NETCOLOGNE-MNT 312 http://www.ripe.net/db/state/maintainers/NETCOLOGNE-MNT.html 42 SL-CUS-MNT 292 http://www.ripe.net/db/state/maintainers/SL-CUS-MNT.html 43 AS3233-MNT 283 http://www.ripe.net/db/state/maintainers/AS3233-MNT.html 44 AS5617-MNT 281 http://www.ripe.net/db/state/maintainers/AS5617-MNT.html 45 FREENAME-NOC 278 http://www.ripe.net/db/state/maintainers/FREENAME-NOC.html 46 TRMD-MNT 261 http://www.ripe.net/db/state/maintainers/TRMD-MNT.html 47 DNSNET-MNT 258 http://www.ripe.net/db/state/maintainers/DNSNET-MNT.html 48 GIGABELL-MNT 257 http://www.ripe.net/db/state/maintainers/GIGABELL-MNT.html 49 NETTUNO 257 http://www.ripe.net/db/state/maintainers/NETTUNO.html 50 AS1717-MNT 243 http://www.ripe.net/db/state/maintainers/AS1717-MNT.html 51 MBT-MNT 236 http://www.ripe.net/db/state/maintainers/MBT-MNT.html 52 AS5378-MNT 235 http://www.ripe.net/db/state/maintainers/AS5378-MNT.html 53 EUROCONNECT 231 http://www.ripe.net/db/state/maintainers/EUROCONNECT.html 54 AS5427-MNT 227 http://www.ripe.net/db/state/maintainers/AS5427-MNT.html 55 IMAGINET-NOC-MNT 225 http://www.ripe.net/db/state/maintainers/IMAGINET-NOC-MNT.htm 56 PRHO-GUARDIAN 218 http://www.ripe.net/db/state/maintainers/PRHO-GUARDIAN.html 57 IBGNET 215 http://www.ripe.net/db/state/maintainers/IBGNET.html 58 NDH-P 211 http://www.ripe.net/db/state/maintainers/NDH-P.html 59 AS2120-MNT 209 http://www.ripe.net/db/state/maintainers/AS2120-MNT.html 60 IWAY-NOC 201 http://www.ripe.net/db/state/maintainers/IWAY-NOC.html 61 ONE2ONE-MNT 200 http://www.ripe.net/db/state/maintainers/ONE2ONE-MNT.html 62 ROM-MIKNET 194 http://www.ripe.net/db/state/maintainers/ROM-MIKNET.html 63 SKYNETBE-MNT 185 http://www.ripe.net/db/state/maintainers/SKYNETBE-MNT.html 64 AS2529-MNT 183 http://www.ripe.net/db/state/maintainers/AS2529-MNT.html 65 IT-NIC 176 http://www.ripe.net/db/state/maintainers/IT-NIC.html 66 AS1899-MNT 171 http://www.ripe.net/db/state/maintainers/AS1899-MNT.html 67 AS1241-MNT 169 http://www.ripe.net/db/state/maintainers/AS1241-MNT.html 68 EU-IBM-NIC-MNT2 169 http://www.ripe.net/db/state/maintainers/EU-IBM-NIC-MNT2.html 69 PSINET-UK-SYSADMIN 159 http://www.ripe.net/db/state/maintainers/PSINET-UK-SYSADMIN.h 70 OMNILINK-MNT 151 http://www.ripe.net/db/state/maintainers/OMNILINK-MNT.html 71 AS2871-MNT 150 http://www.ripe.net/db/state/maintainers/AS2871-MNT.html 72 AS5551-MNT 143 http://www.ripe.net/db/state/maintainers/AS5551-MNT.html 73 ISTLD-MNT 143 http://www.ripe.net/db/state/maintainers/ISTLD-MNT.html 74 AS6721-MNT 142 http://www.ripe.net/db/state/maintainers/AS6721-MNT.html 75 KDT-MNT 141 http://www.ripe.net/db/state/maintainers/KDT-MNT.html 76 WEBSPACE-SERVICE-DE 141 http://www.ripe.net/db/state/maintainers/WEBSPACE-SERVICE-DE. 77 NNCC 135 http://www.ripe.net/db/state/maintainers/NNCC.html 78 EVOSYS-MNT 133 http://www.ripe.net/db/state/maintainers/EVOSYS-MNT.html 79 DK-NIC 128 http://www.ripe.net/db/state/maintainers/DK-NIC.html 80 ICMS-NOC-MAINTAINER 124 http://www.ripe.net/db/state/maintainers/ICMS-NOC-MAINTAINER. 81 ITNET-MNT 124 http://www.ripe.net/db/state/maintainers/ITNET-MNT.html 82 SEICOM-MNT 119 http://www.ripe.net/db/state/maintainers/SEICOM-MNT.html 83 AS3292-MNT 117 http://www.ripe.net/db/state/maintainers/AS3292-MNT.html 84 ISMA-MNT 117 http://www.ripe.net/db/state/maintainers/ISMA-MNT.html 85 COMMPLEX-MNT 107 http://www.ripe.net/db/state/maintainers/COMMPLEX-MNT.html 86 INETWIRE-MNT 107 http://www.ripe.net/db/state/maintainers/INETWIRE-MNT.html 87 ISB-MNT 107 http://www.ripe.net/db/state/maintainers/ISB-MNT.html 88 PROFI-MNT 105 http://www.ripe.net/db/state/maintainers/PROFI-MNT.html 89 MDA-Z 100 http://www.ripe.net/db/state/maintainers/MDA-Z.html 90 ROSNIIROS-MNT 99 http://www.ripe.net/db/state/maintainers/ROSNIIROS-MNT.html 91 ODN-MNT 96 http://www.ripe.net/db/state/maintainers/ODN-MNT.html 92 SPACENET-P 96 http://www.ripe.net/db/state/maintainers/SPACENET-P.html 93 XMS-MNT 94 http://www.ripe.net/db/state/maintainers/XMS-MNT.html 94 AS8875-MNT 90 http://www.ripe.net/db/state/maintainers/AS8875-MNT.html 95 WEB4YOU-MNT 88 http://www.ripe.net/db/state/maintainers/WEB4YOU-MNT.html 96 SCHUETZ-MNT 87 http://www.ripe.net/db/state/maintainers/SCHUETZ-MNT.html 97 OMC1-RIPE-MNT 84 http://www.ripe.net/db/state/maintainers/OMC1-RIPE-MNT.html 98 AS1267-MNT 83 http://www.ripe.net/db/state/maintainers/AS1267-MNT.html 99 MAINT-AS3352 83 http://www.ripe.net/db/state/maintainers/MAINT-AS3352.html 100 TINET-NOC 83 http://www.ripe.net/db/state/maintainers/TINET-NOC.html From stephenb at uk.uu.net Tue Jan 11 12:49:34 2000 From: stephenb at uk.uu.net (stephenb at uk.uu.net) Date: Tue, 11 Jan 2000 11:49:34 +0000 (GMT) Subject: DB consistancy checking tools Message-ID: <200001111203.NAA21648@birch.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 at uk.uu.net Phone: +44 (0)1223 581051 Stephen Burley EMEA Registrar UUNET ---------------------------------- From hph at infostream.no Tue Jan 11 23:43:30 2000 From: hph at infostream.no (Hans Petter Holen) Date: Tue, 11 Jan 2000 23:43:30 +0100 Subject: LIR-34.4 Form a task force for documenting the existing policy process Message-ID: <009c01bf5c85$4a52a840$e406e1c3@dont.no> 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 From hph at infostream.no Tue Jan 11 22:24:31 2000 From: hph at infostream.no (Hans Petter Holen) Date: Tue, 11 Jan 2000 22:24:31 +0100 Subject: New RIPE NCC Website References: <200001101756.SAA04026@birch.ripe.net> Message-ID: <007201bf5c7a$407f18e0$e406e1c3@dont.no> 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" To: "Local Internet Registries in Europe" ; "Reseaux IP Europeens" 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 . > > Regards, > > Paul Rendek > Communications Officer > From hph at infostream.no Tue Jan 11 23:23:18 2000 From: hph at infostream.no (hph at infostream.no) Date: Tue, 11 Jan 2000 23:23:18 +0100 Subject: LIR 34.11 Discuss moving IPv6 policy matters to lir-wg Message-ID: <200001112223.XAA01349@gaustad.sys.sol.no> 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. From hph at infostream.no Tue Jan 11 22:28:37 2000 From: hph at infostream.no (Hans Petter Holen) Date: Tue, 11 Jan 2000 22:28:37 +0100 Subject: LIR-34.1 Suggest clarification of WG charter Message-ID: <007801bf5c7a$d64e89a0$e406e1c3@dont.no> 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. From woeber at cc.univie.ac.at Wed Jan 12 11:36:25 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 12 Jan 2000 11:36:25 MET Subject: LIR 34.11 Discuss moving IPv6 policy matters to lir-wg Message-ID: <009E4079.B8BD1814.15@cc.univie.ac.at> 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 at 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 __________________________________________________________________________ From jhma at EU.net Fri Jan 14 18:59:36 2000 From: jhma at EU.net (James Aldridge) Date: Fri, 14 Jan 2000 18:59:36 +0100 Subject: LIR-WG Action LIR-34.8 - Additional values for the inetnum status field Message-ID: <200001141759.SAA07181@aegir.EU.net> 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. From hph at infostream.no Tue Jan 18 23:15:10 2000 From: hph at infostream.no (hph at infostream.no) Date: Tue, 18 Jan 2000 23:15:10 +0100 Subject: LIR.34.6 Define final Address council selection procedure Message-ID: <200001182215.XAA26004@gaustad.sys.sol.no> 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 From samc at uu.net Wed Jan 19 15:29:24 2000 From: samc at uu.net (Sam Critchley) Date: Wed, 19 Jan 2000 15:29:24 +0100 (MET) Subject: RIPE hostmasters visiting LIRs Message-ID: 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 at uu.net Tel: +31 20 711 6082 ******************** From ripe-dbm at ripe.net Wed Jan 19 21:06:41 2000 From: ripe-dbm at ripe.net (RIPE Database Administration) Date: Wed, 19 Jan 2000 21:06:41 +0100 Subject: Top 100 Maintainers List 20000119 Message-ID: <200001192006.VAA01942@birch.ripe.net> Dear list members, This is biweekly report on inconsistent objects in the RIPE whois database. The first 100 maintainers are listed as a table below sorted according to number of their inconsistent objects in the database. The rest of the maintainers which have inconsistent objects can be found at http://www.ripe.net/ripencc/pub-services/db/state/mntnerreport1.html You can find further information about the Consistency Project at http://www.ripe.net/ripencc/pub-services/db/state/ Regards, RIPE NCC Database Group =============================================================== Maintainer no of name inconsistent objects 1 DENIC-P 55002 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DENIC-P.html 2 XLINK-MNT 49872 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/XLINK-MNT.html 3 DK-DOMREG 9948 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DK-DOMREG.html 4 ROKA-P 3718 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ROKA-P.html 5 DTAG-NIC 3585 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DTAG-NIC.html 6 ECCE-NOC 2809 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ECCE-NOC.html 7 SCHLUND-P 2457 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/SCHLUND-P.html 8 FR-NIC-MNT 1860 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/FR-NIC-MNT.html 9 DREIMARK49-MNT 1844 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DREIMARK49-MNT.html 10 ABCAG-MNT 1762 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ABCAG-MNT.html 11 BO-DOMREG 1694 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/BO-DOMREG.html 12 NACAMAR-NOC 1602 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/NACAMAR-NOC.html 13 WWW-MNT 1438 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/WWW-MNT.html 14 DENIC-N 1039 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DENIC-N.html 15 AS1849-MNT 833 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS1849-MNT.html 16 HIGHSPEED-DOM 814 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/HIGHSPEED-DOM.html 17 ECORE-NET 813 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ECORE-NET.html 18 INTERNET-NOC 703 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/INTERNET-NOC.html 19 CSL-MNT 587 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/CSL-MNT.html 20 DKNET-MNT 580 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DKNET-MNT.html 21 SEKTORNET-MNT 575 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/SEKTORNET-MNT.html 22 DFN-NTFY 562 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DFN-NTFY.html 23 NACAMAR-RES 504 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/NACAMAR-RES.html 24 DE-VOSS 500 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DE-VOSS.html 25 DNSNET-MNT 461 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DNSNET-MNT.html 26 TDK-MNT 443 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/TDK-MNT.html 27 GLOBAL-MNT 442 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/GLOBAL-MNT.html 28 SDT-NOC 433 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/SDT-NOC.html 29 IL-P 429 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/IL-P.html 30 RAK-NET 400 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/RAK-NET.html 31 WESPE-MNT 388 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/WESPE-MNT.html 32 OLEANE-NOC 384 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/OLEANE-NOC.html 33 KNIPP-NOC-MNT 381 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/KNIPP-NOC-MNT.html 34 IDNET-MNT 373 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/IDNET-MNT.html 35 NACAMAR-POP 365 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/NACAMAR-POP.html 36 MARIDAN-P 364 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/MARIDAN-P.html 37 DIGITALWEB-MNT 359 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DIGITALWEB-MNT.html 38 RAIN-TRANSPAC 358 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/RAIN-TRANSPAC.html 39 INX-MNT 333 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/INX-MNT.html 40 NETCOLOGNE-MNT 330 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/NETCOLOGNE-MNT.html 41 GIGABELL-MNT 327 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/GIGABELL-MNT.html 42 AS6678-MNT 323 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS6678-MNT.html 43 SL-CUS-MNT 320 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/SL-CUS-MNT.html 44 NETTUNO 307 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/NETTUNO.html 45 AS3233-MNT 302 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS3233-MNT.html 46 AS5617-MNT 295 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS5617-MNT.html 47 FREENAME-NOC 294 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/FREENAME-NOC.html 48 TRMD-MNT 293 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/TRMD-MNT.html 49 MBT-MNT 262 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/MBT-MNT.html 50 AS5378-MNT 248 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS5378-MNT.html 51 AS5427-MNT 246 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS5427-MNT.html 52 AS1717-MNT 237 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS1717-MNT.html 53 PRHO-GUARDIAN 236 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/PRHO-GUARDIAN.html 54 EUROCONNECT 230 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/EUROCONNECT.html 55 IMAGINET-NOC-MNT 226 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/IMAGINET-NOC-MNT.html 56 ONE2ONE-MNT 224 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ONE2ONE-MNT.html 57 IBGNET 221 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/IBGNET.html 58 NDH-P 219 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/NDH-P.html 59 AS2120-MNT 207 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS2120-MNT.html 60 ROM-MIKNET 204 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ROM-MIKNET.html 61 IWAY-NOC 195 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/IWAY-NOC.html 62 AS1899-MNT 194 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS1899-MNT.html 63 KDT-MNT 194 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/KDT-MNT.html 64 AS2529-MNT 189 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS2529-MNT.html 65 EU-IBM-NIC-MNT2 188 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/EU-IBM-NIC-MNT2.html 66 PSINET-UK-SYSADMIN 188 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/PSINET-UK-SYSADMIN.html 67 SKYNETBE-MNT 186 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/SKYNETBE-MNT.html 68 AS2871-MNT 182 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS2871-MNT.html 69 FR-EASYNET 176 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/FR-EASYNET.html 70 IT-NIC 176 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/IT-NIC.html 71 WEBSPACE-SERVICE-DE 164 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/WEBSPACE-SERVICE-DE.html 72 AS1241-MNT 162 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS1241-MNT.html 73 ITNET-MNT 162 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ITNET-MNT.html 74 OMNILINK-MNT 155 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/OMNILINK-MNT.html 75 ISTLD-MNT 150 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ISTLD-MNT.html 76 AS6721-MNT 148 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS6721-MNT.html 77 EVOSYS-MNT 144 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/EVOSYS-MNT.html 78 NNCC 135 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/NNCC.html 79 ICMS-NOC-MAINTAINER 134 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ICMS-NOC-MAINTAINER.html 80 SEICOM-MNT 128 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/SEICOM-MNT.html 81 IVM-MNT 126 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/IVM-MNT.html 82 ISMA-MNT 120 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ISMA-MNT.html 83 AS3292-MNT 119 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS3292-MNT.html 84 SPACENET-P 117 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/SPACENET-P.html 85 COMMPLEX-MNT 116 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/COMMPLEX-MNT.html 86 PROFI-MNT 116 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/PROFI-MNT.html 87 DK-NIC 113 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/DK-NIC.html 88 INETWIRE-MNT 113 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/INETWIRE-MNT.html 89 XMS-MNT 109 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/XMS-MNT.html 90 AS5551-MNT 105 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS5551-MNT.html 91 ODN-MNT 101 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ODN-MNT.html 92 ROSNIIROS-MNT 99 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ROSNIIROS-MNT.html 93 AS8875-MNT 95 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/AS8875-MNT.html 94 MDA-Z 94 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/MDA-Z.html 95 SCHUETZ-MNT 92 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/SCHUETZ-MNT.html 96 WEB4YOU-MNT 91 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/WEB4YOU-MNT.html 97 OMC1-RIPE-MNT 90 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/OMC1-RIPE-MNT.html 98 VISCOMP-MNT 87 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/VISCOMP-MNT.html 99 ISB-MNT 85 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/ISB-MNT.html 100 CU-MNT 84 http://www.ripe.net/ripencc/pub-services/db/state/maintainers/CU-MNT.html From woeber at cc.univie.ac.at Thu Jan 20 13:07:19 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 20 Jan 2000 13:07:19 MET Subject: DB consistancy checking tools Message-ID: <009E46CF.BF056BE8.5@cc.univie.ac.at> With reference to: >From: stephenb at uk.uu.net >Date: Tue, 11 Jan 2000 11:49:34 +0000 (GMT) >Subject: DB consistancy checking tools >To: lir-wg at 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 at 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. From matthew at planet.net.uk Thu Jan 20 13:32:52 2000 From: matthew at planet.net.uk (Matthew Robinson) Date: Thu, 20 Jan 2000 12:32:52 -0000 Subject: DB consistancy checking tools Message-ID: <6BF1C330AF53D311BE5D00508B09081001E3FBFD@PLANET01> 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 at cc.univie.ac.at] Sent: 20 January 2000 13:07 To: stephenb at uk.uu.net Cc: lir-wg at ripe.net; woeber at cc.univie.ac.at; db-wg at ripe.net Subject: RE: DB consistancy checking tools From woeber at cc.univie.ac.at Thu Jan 20 14:54:56 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 20 Jan 2000 14:54:56 MET Subject: DB consistancy checking tools Message-ID: <009E46DE.C79A15D8.6@cc.univie.ac.at> 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 at 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 __________________________________________________________________________ From matthew at planet.net.uk Thu Jan 20 17:17:20 2000 From: matthew at planet.net.uk (Matthew Robinson) Date: Thu, 20 Jan 2000 16:17:20 -0000 Subject: DB consistancy checking tools Message-ID: <6BF1C330AF53D311BE5D00508B09081001E3FBFE@PLANET01> 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 at cc.univie.ac.at] Sent: 20 January 2000 14:55 To: matthew at planet.net.uk Cc: lir-wg at ripe.net; db-wg at ripe.net; woeber at 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. From alipour at technologist.com Fri Jan 21 16:16:08 2000 From: alipour at technologist.com (Hamid Alipour) Date: Fri, 21 Jan 2000 18:46:08 +0330 Subject: minutes References: <20000120205718.B20899@Qwest.com> Message-ID: <001501bf6422$d1dab420$e5e3c8c3@iranpac.net.ir> 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 To: Cc: 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 :-) > > > -- > From alipour at technologist.com Fri Jan 21 19:26:33 2000 From: alipour at technologist.com (Hamid Alipour) Date: Fri, 21 Jan 2000 21:56:33 +0330 Subject: minutes References: <001501bf6422$d1dab420$e5e3c8c3@iranpac.net.ir> <20000120205718.B20899@Qwest.com> <200001211633.e0LGXS492349@dblab.ece.ntua.gr> Message-ID: <002301bf643d$a473d320$e5e3c8c3@iranpac.net.ir> I would like to mention that my main job is designing and implementing internet rather than telephony network. I know that there is some similarities and differences between this two networks. the thing that I didn't know was that telephony services are geographically bounded!! well, I am not going to do a comparison between this two networks and I leave talking about this subject here. The thing that I would like to remind is that the decision making about two letter country TLDs subdomains are given to LIRs residing in the same country.I would like to ask why the same approach is not implemented about IPv6 address space allocation. there is a large address space and we can allocate a prefix to each country.the allocation inside country's allocated address space can be left for a LIR inside that country.in this way address space fragmentation can be avoided. it was not possible in IPv4 because of small address space that was available by IPv4. all policies ( classless address space allocation, designing procedures by which a LIR or RIR to become sure that address space is really needed and so on) was because the address space was limited and IR's decided to extend the life of IPv4 and minimize address space consumption.the things are different in IPv6.why should the same procedures be used in IPv6 address space allocation?having a large address space the network can be designed very easier and better Best Regards Hamid Alipour ----- Original Message ----- From: Yiorgos Adamopoulos To: Hamid Alipour Cc: David Kessens ; ; Sent: Friday, January 21, 2000 8:01 PM Subject: Re: minutes > Message-ID: > Priority: NORMAL > X-Mailer: Execmail for Win32 Version 5.0.1 Build (55) > MIME-Version: 1.0 > Content-Type: Text/Plain; charset="us-ascii" > > On Fri, 21 Jan 2000 18:46:08 +0330 Hamid Alipour > wrote: > > > 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 > > Among other things, Internet networks are not geographically bounded > the way that telephone networks are. Hence, what you propose has no > meaning. > ------------------------------------ > Yiorgos Adamopoulos > > From alipour at technologist.com Sat Jan 22 08:25:27 2000 From: alipour at technologist.com (Hamid Alipour) Date: Sat, 22 Jan 2000 10:55:27 +0330 Subject: minutes References: <002301bf643d$a473d320$e5e3c8c3@iranpac.net.ir> <001501bf6422$d1dab420$e5e3c8c3@iranpac.net.ir> <20000120205718.B20899@Qwest.com> <200001211633.e0LGXS492349@dblab.ece.ntua.gr> <200001211917.e0LJHX499519@dblab.ece.ntua.gr> Message-ID: <000e01bf64a9$e2f01a20$e5e3c8c3@iranpac.net.ir> > > The thing that I would like to remind is that > > the decision making about two letter country TLDs > > subdomains are given to LIRs residing in the same > > country.I would like to ask why the same approach is > > not implemented about IPv6 address space allocation. > > Because a host ending in .gr is not obliged to reside withing the > geographical boundaries of Greece (and this is true for many country > TLDs). Also, you have .com, .net, .org, .edu (and comming .inc > .whatever) TLDs that are not bounded within a country. This is the > case for TLDs. > > Now immagine this: > > You have company A based say in Greece. Now company A opens offices AB > in Bulgaria. Should company A get another address space slice for AB > offices, or should it use addresses from the A slice, assuming there > exists a direct connection from A to AB? > > Why make things more complicate than they already are? The geography > on the Internet is different that the "physical" one, which is the one > the Telcos use. 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 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. currently I have to run a procedure for each end user who whishes to get address space and I have ensure RIPE that the address space is really needed.end users do not have this permistion to reserve address space. 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. Best Regards Hamid Alipour > ------------------------------------ > Yiorgos Adamopoulos > > From adamo at dblab.ece.ntua.gr Fri Jan 21 17:31:32 2000 From: adamo at dblab.ece.ntua.gr (Yiorgos Adamopoulos) Date: Fri, 21 Jan 2000 18:31:32 +0200 Subject: minutes In-Reply-To: <001501bf6422$d1dab420$e5e3c8c3@iranpac.net.ir> References: <001501bf6422$d1dab420$e5e3c8c3@iranpac.net.ir> <20000120205718.B20899@Qwest.com> Message-ID: <200001211633.e0LGXS492349@dblab.ece.ntua.gr> Message-ID: Priority: NORMAL X-Mailer: Execmail for Win32 Version 5.0.1 Build (55) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" On Fri, 21 Jan 2000 18:46:08 +0330 Hamid Alipour wrote: > 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 Among other things, Internet networks are not geographically bounded the way that telephone networks are. Hence, what you propose has no meaning. ------------------------------------ Yiorgos Adamopoulos From adamo at dblab.ece.ntua.gr Fri Jan 21 20:15:36 2000 From: adamo at dblab.ece.ntua.gr (Yiorgos Adamopoulos) Date: Fri, 21 Jan 2000 21:15:36 +0200 Subject: minutes In-Reply-To: <002301bf643d$a473d320$e5e3c8c3@iranpac.net.ir> References: <002301bf643d$a473d320$e5e3c8c3@iranpac.net.ir> <001501bf6422$d1dab420$e5e3c8c3@iranpac.net.ir> <20000120205718.B20899@Qwest.com> <200001211633.e0LGXS492349@dblab.ece.ntua.gr> Message-ID: <200001211917.e0LJHX499519@dblab.ece.ntua.gr> Message-ID: Priority: NORMAL X-Mailer: Execmail for Win32 Version 5.0.1 Build (55) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" On Fri, 21 Jan 2000 21:56:33 +0330 Hamid Alipour wrote: > The thing that I would like to remind is that > the decision making about two letter country TLDs > subdomains are given to LIRs residing in the same > country.I would like to ask why the same approach is > not implemented about IPv6 address space allocation. Because a host ending in .gr is not obliged to reside withing the geographical boundaries of Greece (and this is true for many country TLDs). Also, you have .com, .net, .org, .edu (and comming .inc .whatever) TLDs that are not bounded within a country. This is the case for TLDs. Now immagine this: You have company A based say in Greece. Now company A opens offices AB in Bulgaria. Should company A get another address space slice for AB offices, or should it use addresses from the A slice, assuming there exists a direct connection from A to AB? Why make things more complicate than they already are? The geography on the Internet is different that the "physical" one, which is the one the Telcos use. ------------------------------------ Yiorgos Adamopoulos From roconnell at olf.co.uk Sat Jan 22 22:12:09 2000 From: roconnell at olf.co.uk (Ryan O`Connell) Date: Sat, 22 Jan 2000 21:12:09 -0000 (GMT) Subject: IPv6 address prefixes [Was: minutes] In-Reply-To: <000e01bf64a9$e2f01a20$e5e3c8c3@iranpac.net.ir> Message-ID: On 22-Jan-2000 Hamid Alipour wrote: > The thing that I would like you consider is that we have enough address > space availble trough IPv6.I have two remarks here: One of the goals of the current RIR system is not just conservation of address space but aggregation of routes. Many companies and ISPs span several countries. A Europe-wide company, under a telephone-style routing-prefix system, would require 30 or so independant routing prefixes. Similar situations exist in America and Asia-Pacific. Even a four-fold increase in the size of the routing tables would bring most of the backbone routers to their knees. -- Ryan O'Connell - On:Line Finance IT Department - Direct Voice Line: 01932 704320 Fax: 0870 242 2201 "Hey, girls, watch out for the wierdos" "Mister, we ARE the wierdos" From woeber at cc.univie.ac.at Mon Jan 24 16:55:58 2000 From: woeber at cc.univie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Mon, 24 Jan 2000 16:55:58 MET Subject: minutes Message-ID: <009E4A14.5971F074.6@cc.univie.ac.at> 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 at 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 __________________________________________________________________________ From hph at infostream.no Tue Jan 25 22:32:03 2000 From: hph at infostream.no (Hans Petter Holen) Date: Tue, 25 Jan 2000 22:32:03 +0100 Subject: LIR-34.4 Form a task force for documenting the existing policy process References: <009c01bf5c85$4a52a840$e406e1c3@dont.no> Message-ID: <008a01bf677e$04d56f60$e406e1c3@dont.no> Dear (non ?)-Working Group ! > 24/1 Close of discussion on list There has been no comments what so ever to the list ! I have received some comments privately, but shurely, the community must be more interested than this in participating in future deveopment of policy in the RIPE region ? I am under no circumstances going to accept that my first draft describes the collective opinion of this working group on how we have developed policy so far. I am looking for comments like - could you please expain what you mean by "xxxxx" - it should realy say "yyy" shouldn't it ? Extending the deadline for another week ! -hph From hph at infostream.no Tue Jan 25 22:32:07 2000 From: hph at infostream.no (Hans Petter Holen) Date: Tue, 25 Jan 2000 22:32:07 +0100 Subject: LIR-34.4 Form a task force for documenting the existing policy process References: <009c01bf5c85$4a52a840$e406e1c3@dont.no> Message-ID: <008b01bf677e$054aed80$e406e1c3@dont.no> Dear (non ?)-Working Group ! > 24/1 Close of discussion on list There has been no comments what so ever to the list ! I have received some comments privately, but shurely, the community must be more interested than this in participating in future deveopment of policy in the RIPE region ? I am under no circumstances going to accept that my first draft describes the collective opinion of this working group on how we have developed policy so far. I am looking for comments like - could you please expain what you mean by "xxxxx" - it should realy say "yyy" shouldn't it ? Extending the deadline for another week ! -hph From hph at infostream.no Tue Jan 25 22:49:03 2000 From: hph at infostream.no (Hans Petter Holen) Date: Tue, 25 Jan 2000 22:49:03 +0100 Subject: LIR.34.6 Define final Address council selection procedure References: <200001182215.XAA26004@gaustad.sys.sol.no> Message-ID: <008c01bf677e$05b743e0$e406e1c3@dont.no> To set of this discussion let me propose the following procedure: - Anyone may nominate anyone within the restrictions of the MOU - Each nomination, after acceptance, should seek support from at least 3 other persons. - Everybody subscribed to ripe-ac-voting may vote (Initialy everybody subscribed to any RIPE list will be invited to subscribe to this list) Each individual may give n votes where n = c * (1 + (10 * r) + p) where c is the number of candidates to be eleced in this particular election (normaly 1) and r is the number of ripe meetings the person has atteded and p is the number of contributions to a well defined set of the ripe mailig lists - The vote will be open for at least two weeks, and until more than 50 % of the subscribers to the list have voted. - The result of the vote will be made publicly available and individual votes may be challenged for a period of two weeks (ie the person who as given the vote must identify himself to the community) This process should, with some further refinement, satisfy the requirements of ICANN and the ASO MoU to be open and transparent. With hopes for a lively discussion, Yours the chair. From Daniel.Karrenberg at ripe.net Wed Jan 26 22:27:13 2000 From: Daniel.Karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 26 Jan 2000 22:27:13 +0100 Subject: LIR.34.6 Define final Address council selection procedure In-Reply-To: <008c01bf677e$05b743e0$e406e1c3@dont.no> References: <200001182215.XAA26004@gaustad.sys.sol.no> Message-ID: <4.2.0.58.20000126222604.01589e50@localhost.ripe.net> Counting contributions to mailing lists is a sure fire way to decrease the S/N ratio of said lists. Don't do it. One man one vote. Respectfully Daniel From amar at telia.net Thu Jan 27 00:23:24 2000 From: amar at telia.net (Amar) Date: Thu, 27 Jan 2000 00:23:24 +0100 Subject: LIR.34.6 Define final Address council selection procedure References: <200001182215.XAA26004@gaustad.sys.sol.no> Message-ID: <388F81EC.E5639EA9@telia.net> Hi, Well I have to admit that I have not been engaged in this process lately. But here is a few thoughts to start with: > The most relevant points being: > - Can an individual nominate themselves? Yes. Otherwise there with be a limitation of nominees from "remote" areas who have not been able to make them self heard thru the years. But who would be able to contribute to the RIPE community. > - Does the nomination need to come from more than one person? No. As long that there is information about what person nominated who. > To the selection procedure in particular at least the following needs > to be defined: > > - Who performs the selection Do You mean the selection of nominees or a Nomination Comittee? The previously elected group would appoint a Chairman of the Nomination Comittee ( NC ). The chairman calls publicly for participants in the nominations committee, and receives suggestions from the community. The list of all suggestions is presented in public, and the community can comment on them. Given the list and comments, the previously elected board elect the NC. The NC then asks the community for nominees for the ASO. Following the rules set regarding who can be nominated. After the nominees have been submitted - and confirmed by the nominee - the list can be published. The woting of the reps. to the ASO is the perfomed on the annual member meeting - or a public meeting? > - In what way is the selection performed This is a tricky one. Should every member get one wote? Or one wote per LIR? > 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 suggest direct on the meeting, or thru a proxy that is hold by another member, or by fax. How the authentication should be performed by "electronic" media I do not know. PGP? Suggestions? Regards -- amar Telia Net