August 1999 - 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

Tracking stealth portscan/pepsi attacks
by Petra Zeidler 07 Sep '99

07 Sep '99

Dear colleagues, there seems to have been quite a wash of stealth portscans and/or pepsi attacks lately (stealth portscan: you portscan with 99% of the sender addresses faked, but your own are among them; pepsi: "only" a DoS attack, you don't bother hiding your own address in the random sender flood, both of course UDP). cybercity.dk must have been seeing some of these attacks pass, first glance judging from http://stat.cybercity.dk/ripe/ and the fallout in de.xlink (where I positively know the addresses not to be routed) and de.zz (where most of the address space is handled by RIPE nowadays). Also my private machine at home has been attacked over several days, much good it did them, but that makes it a personal axe to grind :-> Besides, lots of people who admin firewalls don't necessarily expect such stealth attacks to happen and complain to all the owners of the faked addresses about the port scans, thus generation additional workload on the abuse people. I'd like to have a chance to catch the perpetrators. This would need to be a multi-provider cooperation in the majority of cases. Do we have an appropriate forum to discuss this at the next RIPE meeting? kind regards, Petra Zeidler -- i.A. Petra Zeidler, Neukundenanschluss Xlink Internet Service GmbH [X] zeidler(a)xlink.net [X] Tel: 0721/9652-220 [X] Fax: 0721/9652-209 [X] Geschaeftsfuehrer: Michael Rotert. Amtsgericht Karlsruhe HRB 8161. [X] Auftraege erledigen wir zu unseren Allgemeinen Geschaeftsbedingungen.

14 24

Call for agenda items to the RIPE Local Internet Registry Workin Group
by hph＠sys.sol.no 30 Aug '99

30 Aug '99

Dear Working Group, Summer is almost over and there will soon be a RIPE meeting, and at that RIPE meeting a Local Internet Registry Working Group. Since we were extremely efficient at the last meeting we have 0 - zero - open action points, so it will be even harder for me to put together an agenda this time. This is the reason for this message. What do YOU want us to do at the next meeting? Shall we limit the WG to the registry reports or are there other matters that needs to be discussed? Lots of things are happening in our area, a proposal for an address-supporting organisation in ICANN (see http://www.icann.org/comments-mail/comment-aso/maillist.html) has been circulated among the membership and submitted to the ICANN board. Some of the discussion has taken on aso-discuss(a)ripe.net and yet some on comment-aso(a)icann.org which can be viewed at http://www.icann.org/comments-mail/comment-aso/maillist.html . But when the discussion has ended and there is consensus, the real work start, how do we appoint our representatives to the ASO, and who do we want oversee the future of the Internet, both at the ASO and on the ICANN board? Should we discuss this topic in any flavour in the working group or should we leave this for the plenary? In the ICANN process the openness of our policy-making procedures has been repeatedly questioned by external voices. Not very concrete and therefor not very constructive. Maybe we should rise above that and still discuss this. Maybe our policy-making procedures seem closed because nobody knows what they are and how they work? IANA has allocated addresses to the regional registries. What implications does this have? Should this still be a matter for the IPv6 WG only or should some aspects of IPv6 such as evolving the policy document, be included on our agenda. (Or even, do we know enough about IPv6?) Then of course there may be concrete policy issues or other topics you would like on the agenda. Feel free to air your opinions at this list or to me. I plan to circulate a draft agenda early next week, and make one or two updates before the meeting. Hans Petter Holen LIR-WG Chair.

1 0

Final RIR ASO Proposal Submission to ICANN
by Mirjam Kuehne 27 Aug '99

27 Aug '99

Dear Colleagues, Thank you very much for the support received regarding the 'Draft proposal for a MoU-based ASO'. As you know, your support is essential to the process and therefore very much appreciated. Discussions following the announcement of the draft proposal on 8 July 1999, and at the recent open ASO meeting which took place at the IETF in Oslo, modifications to the draft proposal were suggested. Following discussions between the RIR excecutive boards, taking into account the collective interests of our communities, further adjustments were made to the proposal which we believe will enhance the prospect of its adoption by ICANN. A proposal for the formation of an ASO has now been formally submitted to ICANN jointly by the Regional Internet Registries: APNIC, ARIN and RIPE NCC. The 'Proposal for a MoU-based ASO' can be found on the RIPE NCC Web site under the 'Current Issues' section at: http://www.ripe.net/info/ncc/icann.html Below please find the modified sections of the draft text as well as comments supporting the motivation for each of these changes. As the adjustments to this proposal have been made for clarity purposes to ensure fair and open processes in all regions, we hope that we can count on your continued support. Kind Regards, Mirjam Kuehne RIPE NCC 2. The Address Council. a. Members. ----------- [original text:] Each RIR signatory of the MOU will appoint two [2] individuals to the Address Council by means of their own choosing. No individual can serve on the Address Council and be on the staff of a RIR at the same time. [final version:] Each RIR signatory of the MOU will select three [3] individuals to the Address Council using the following process: i Annually the RIR will 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 the RIR. COMMENTS: Concerns were raised that having only two [2] Address Council members appointed per region would not allow for sufficient representation. Therefore the number was changed to three [3] per RIR signatory. When additional RIRs sign the MoU this will be revised in order to keep the number of Address Council members at a practical size. Principles for the selection of Address Council members were stated in section 3.b. of the original draft proposal. These methods have been refined and included in this section for further clarification. However, please note that the selection process of the Address Council members will be defined by the regions via an open and transparent procedure. b. Term. -------- [original text:] The term of Address Council members will be 2 years. Removal will be pursuant to procedures established through the MOU. (Initial terms will be 1 and 2 years to provide initial conditions for staggered terms.) [final version:] The term of Address Council members will be 3 years. Removal will be pursuant to procedures established through the MOU. (Initial terms will be 1, 2 and 3 years to provide initial conditions for staggered terms.) COMMENTS: With the increased number of Address Coucil members one additonal term has been defined. c. Powers/Duties of the Address Council. ---------------------------------------- ii Qualifications of ICANN Directors. [original text:] No more than 1 of the ASO-appointed Directors may come from the same geographic region. [final version:] a) No more than 1 ASO-appointed Director may come from the same geographic region. (This proposal assumes the regions defined in the ICANN by-laws.) b) No ASO-appointed Director may serve simultaneously on the Address Council. COMMENTS: The additional sentence under a) is to clarify the word 'region' in this context. Parapraph b) was added as no clear prohibition against Address Council members also serving on the ICANN board was stated. d. Address Policy Development. ------------------------------ [final version:] One paragraph was added to this section: In addition the Address Council may accept, for consideration, proposals for changes to global IP address policy from any interested individual. COMMENT: One may imagine a circumstance where it would be more practical to approach the ASO directly to support the fair and open consideration of a proposal in order to stress equal opportunity for all interested parties. In any case, all proposals received by the ASO will be reviewed by the RIR signaories and the community as described in this section following the above noted addition: In all cases when the Address Council reviews proposals for new global policies or proposed modification to existing policies in this area it will first solicit the opinions of all of the RIR signatories of the MOU and of the public. 3. Annual Open Meeting. (General Assembly) a. Hosting an open meeting. --------------------------- [original text:] The Address Council will periodically host an open meeting ("General Assembly") for promoting discussion and receiving input regarding the work of the ASO. A General Assembly meeting will be held once per year, and will permit open participation by all interested individuals. [final version:] The Address Council will periodically host an open meeting ("General Assembly") for promoting discussion and receiving input regarding the work of the ASO. A General Assembly meeting will be held *at least* once per year, and will permit open participation by all interested individuals. COMMENT: It was felt that the number of meetings should not be restricted in this document. The important point here is that there should be *at least* one meeting per year. b. Selection of Address Council Members. ---------------------------------------- [original text:] Ninety days prior to each General Assembly, ICANN and the Address Council shall make an open call for nominations to any potential vacancies in the Address Council. The results of this call will be forwarded to each RIR signatory to the MOU for their information. Each RIR signatory to the ASO MOU will be entitled to select two [2] members of the Address Council by means of its own choosing. The terms of the appointees will be determined by the appointing RIR. [final version:] Ninety days prior to each annual open meeting, ICANN and the Address Council shall make an open call for nominations to any potential vacancies in the Address Council. The results of this call will be forwarded to each RIR signatory to the MOU for their information. Each RIR signatory to the ASO MOU will be entitled to select three [3] members of the Address Council using the process described in Section 2a. COMMENT: This has been changed in order to make the section consistent with the principles outlined in section 2.a (see above). 4. Open Proceedings and Documents. b. ASO Proceedings ------------------ [original text:] All discussions of ASO business will be conducted on or reported on a publicly-archived mailing list accessible through the ICANN/ASO web site. The schedule for the ASO meetings will be posted 90 days in advance of the meeting date. The agenda for the Address Council and annual open meetings will be posted on the ICANN/ASO web site at least 30 days before the meetings. The minutes from all ASO meetings will be publicly posted on the ICANN/ASO web site within 30 days of the meeting. [final version:] All discussions regarding ASO policy formation will be conducted on or reported on a publicly-archived mailing list accessible through the ASO web site. The schedule for the ASO meetings will be posted 90 days in advance of the meeting date. The agenda for the Address Council and annual open meetings will be posted on the ASO web site at least 30 days before the meetings. The minutes from all ASO meetings will be publicly posted on the ASO web site within 30 days of the meeting. In the unlikely event that the policy formation discussions involve confidential commercial data that was presented in an address allocation process the above disclosures must be done in a way to protect the confidentially of that data. COMMENT: The location of the documentation to be published has been more clearly specified (on the ASO web site). The last sentence has been added in order to explicitly exempt confidential data from publication as defined in the existing RIR operational procedures. 6. Recognition. [original text:] 7) That the introduction of a new RIR must be based on a "Sound Business Plan". The plan must be reviewed by ICANN and by the existing RIRs. The process for creating a new RIR must be included in the MOU. [final version:] 6) That the proposed RIR has clearly defined procedures open to all interested parties regarding ensuring fair representation of constituents within the region of coverage in the policy development process. COMMENT: This paragraph was added in order to ensure open and transparent processes of policy development in all new and existing RIRs. For your information, please note that the order of points in appendix A has slightly changed, resulting in the number change noted above.

3 2

Top 100 Maintainers List - 19990820
by RIPE Database Manager 20 Aug '99

20 Aug '99

1 0

Draft minutes from the LIR-WG at RIPE 33
by hph＠sys.sol.no 18 Aug '99

18 Aug '99

Version 1.0 Chair: Hans Petter Holen <hph(a)sys.sol.no> Scribe: Paul Tate, RIPE NCC Hostmaster Participants: approximately 68 RIPE 33 - Local IR Working Group Final Agenda 1. Admin scribe participant list agenda meet the RIPE NCC hostmasters mailinglists 2. RIPE 32 minutes actions 3. Reports from the Registries RIPE: Paula Caslav APNIC: Paul Wilson ARIN: Micahel O'Neill New Regional R (Africa & S. America) brief status by Daniel Karrenberg 4. Tagging IP addresses for Anti Spam purposes 5. AOB Action Points LIR-WG RIPE 32 Done: NCC: Web interface to RIPE 141. Announce, receive comments, and make source public Done: NCC: Get IPv6 Guidelines in place Done: NCC: write up suggestion on lowering AW from /19 Done: Guy Davies, UUnet: Start discussion on list on max allocation size and internal aggregation needs for large networks Done: NCC: Make pretty address statistics charts Done: NCC: IP adresses to cable networks Document current IANA policy and align practice with other IRRs Everybody: Participate in policies for IPv6 discussion Open: tagging of IP addresses for anti SPAM Tagging IP addresses for anti SPAM measures presentation on how the Dialup User List implemented by Paul Vixie works: maps.vix.com discussion on the usefulness of adding mechanisms to the RIPE database took place. Daniel Karrenberg proposed a more general mechanism that would solve this and other needs Passed on to the db wg Action points lir-wg@RIPE 33 All previous actions DONE Many thanks to the RIPE NCC for the good work ! (And to Paula in particular) NO new actions added

1 0

Somebody else trying to use our NCC-Reg-ID
by registry＠gams.co.at 18 Aug '99

18 Aug '99

Dir LIRs! We received this mail yesterday, that someone sends AS requests with our NCC-Reg-ID. I mailed these guys -> no response ... Did someone experience things like that before ! --lg zen Original Mail starts here: > >Dear at.gams staff, > >We have received the below AS request however it has not been signed >by any of the current registered contact people, therefore I should >like to ask you to please resubmit the request by a registered contact >person. > > > Kind regards and thanks :-) > > from > > Pepa Tejedor Carnicero > > ======== > Ripe NCC > ======== > > > root(a)liberty.bulinfo.net writes: > * X-NCC-RegID: at > * .gams > * > * #[AUT-NUM TEMPLATE]# > * > * aut-num: NEW > * descr: Bulinfo Ltd. Autonomous System > * descr: Internet Services Provider > * descr: > * Sofia, Bulgaria > * as-in: from AS9127 100 accept ANY > * as-in: from AS8262 10 accept ANY > * as-out: to AS9127 announce NEW > * as-out: to AS8262 announce NEW > * default: AS9127 > * admin-c: KS2766-RIPE > * tech-c: KS2766-RIPE > * mnt-by: NEW > * changed: krassi(a)bulinfo.net 19990812 > * source: RIPE > * > * #[MAINTAINER TEMPLATE]# > * > * mntner: NEW > * descr: Bulinfo Ltd. AS Maintainer > * admin-c: KS2766-RIPE > * tech-c: KS2766-RIPE > * upd-to: krassi(a)bulinfo.net > * auth: CRYPT-PW BulinfoNet > * mnt-by: NEW > * changed: krassi(a)bulinfo.net 19990812 > * source: RIPE > * > * #[PERSON TEMPLATE]# > * > * person: Kr > * assimir Slavchev > * address: Bu > * linfo Ltd. > * address: Ca > * rnegie 11a str > * address: So > * fia 1000, Bulgaria > * phone: +3 > * 59 2 963 36 52 > * fax-no: +3 > * 59 2 963 37 64 > * e-mail: kr > * assi(a)bulinfo.net > * nic-hdl: > * KS2766-RIPE > * changed: kr > * assi(a)bulinfo.net 19990809 > * source: RI > * PE > * > * #[TEMPLATE END]#

1 0

Please, ignore "my" posting on local-ir
by Berislav Todorovic 06 Aug '99

06 Aug '99

Hello, The message with subject "RE: .DK domain", that I sent a month ago, appeared on the "local-ir" list today. I don't have any idea on the reason. Please, ignore it and apologies for inconvenience. Regards, Beri .-------. | --+-- | Berislav Todorovic, B.Sc.E.E. | E-mail: BERI(a)etf.bg.ac.yu | /|\ Hostmaster of the YU TLD | |-(-+-)-| School of Electrical Engineering | Phone: (+381-11) 3221-419 | \|/ Bulevar Revolucije 73 | 3218-350 | --+-- | 11000 Belgrade SERBIA, YUGOSLAVIA | Fax: (+381-11) 3248-681 `-------' --------------------------------------------------------------------

1 0

Top 100 Maintainers List
by RIPE Database Manager 04 Aug '99

04 Aug '99

2 1