September 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

Announcement of the Address Council members - RIPE NCC Service Region
by RIPE NCC Staff 30 Sep '99

30 Sep '99

Members of the Address Council of ICANN - RIPE NCC Service Region During the 34th RIPE Meeting in Amsterdam on 23 September 1999 three Members of the ICANN ASO Address Council were selected as suggested by the call for nominations of 8th September. The duties of the ICANN Address Council are mainly threefold: First, to advise the Board of ICANN on matters referred to the Address Council by the ICANN Board. Secondly to oversee the existing regional processes for development of global policies relating to distribution and registration of Internet address space, identifiers used in Internet inter-domain routing, and the part of the DNS name space which is derived from the Internet address space and the inter-domain routing identifiers. The third being to appoint Directors to the ICANN Board of Directors in accordance with the By-laws of ICANN. The selection procedure was discussed in the LIR-WG, the open forum for policy issues in RIPE. The selection was performed during the RIPE Plenary meeting. As a pure consensus based selection is highly improbable, the final selection was performed by a secret ballot. The result of this ballot was confirmed by consensus support form the audience. There was also consensus that the three selected candidates should themselves establish their terms. To the best of our knowledge this selection has been in accordance with the principles described in the draft MoU (http://www.ripe.net/info/ncc/mou-draft.html) The selected individuals are: Sabine Jaume, RENATER for a one year period Hans Petter Holen, SOL System for a two year period Wilfried Woeber, Vienna University for a three year period We wish them success and look forward to co-operating with them. Rob Blokzijl Keith Mitchell RIPE chair RIPE NCC chair

1 0

Top 100 maintainers list
by RIPE Database Administration 22 Sep '99

22 Sep '99

1 0

Re: RIPE 34 LIR WG Draft Agenda
by Wilfried Woeber, UniVie/ACOnet 20 Sep '99

20 Sep '99

Hi James, => > "Status: LIR-ALLOCATED" Considered Useful => > ========================================= => => Sounds useful, as long as it's only effect is adding nodes to => the maintainer tree. = =I see its main use as adding nodes to the maintainer tree and also as a way of =documenting use of address space without actually making an assignment. I was using a similar approach/technique for a while to document *revoked* address assignments in the RIPE-DB. My reasoning was that the whole block of addresses being ALLOCATED by the RIR to a particular LIR is *by definition* ALLOCATED Px, unless it is ASSIGNED Px at any particular point in time. From my point of view, any address space from that block *not* being explicitely listed in an inetnum: object with status: ASSIGNED Px, has to be treated as ALLOCATED Px. >Without specific "ASSIGNED" objects below a "LIR-ALLOCATED" object the address >space would still be treated as unassigned as if the new object wasn't there >at all. Exactly. However I was forced (and only partly convinced!) by the hostmasters and Paula C. to stop using that approach. If I recall correctly, there is some interaction with (undocumented?) hostmaster tools/procedures getting things mixed up. (I also mangaged to mix up a human hostmaster...) I understand that more up-to-date SW releases even preclude anyone but the NCC staff from using status: ALLOCTED xx. I don't think this is/was the right direction to go, but that's as it stands right now - to my knowledge. Do we want to re-visit that in either LIR or DB later this week? 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 __________________________________________________________________________

1 0

We think it may be interesting...
by Joao Luis Silva Damas 18 Sep '99

18 Sep '99

Hi, we have just made available some more operational information online for your convenience. Please see http://www.ripe.net/db/mrtg/whois.html Hope you find it useful. It uses the great mrtg tool. Best regards, Joao Damas RIPE DB Group manager RIPE NCC

2 1

RE: New RIPE NCC reverse delegation procedure
by Wilfried Woeber, UniVie/ACOnet 17 Sep '99

17 Sep '99

Hi Lee! >---> It will be mandatory that a registry ID is included in all > requests for reverse delegation, as is currently the case for requests > to <hostmaster(a)ripe.net>. We will require that all requests come from > an LIR receiving service (i.e. paying for services), and > that the requester is one of the registry contact people/ > contact role-account. > > + resource efficient. We only deal with people who are experienced > in the reverse delegation procedure and aware of the RIPE NCC > and RIPE DB procedures in general -> minimal time explaining > procedure and general registry system concepts. Currently > we spend much time dealing with inexperienced end-users who will > set up only one or a few zones and therefore do not spend the > time to become knowledgable concerning the procedures. > > + fair to paying members. We do not spend time guiding people who > do not contribute to the costs. My 1st reaction: this requires a bit more thinking - the people (individuals) running the address assignment business are not necessarily the same persons which deal with DNS. Maybe they should, or the DNs folks should be added to the LIR contacts just for that purpose, but this requires a reality check and procedure review, I suppose? - between the lines, also, this states that users of address space obtained from LIRs which have been closed for one reason or another cannot get RevDNS services set up and/or changed - unless you provide some loopholes. I don't have an opinion about good/bad, it's just an observation. > - for requests involving large numbers of zones lots of > domain objects will be needed. We'll lessen this by > making possible a shorthand domain object like this: > > domain: x-y.w.z.in-addr.arpa > > This will result in all reverse zones x-y being delegated > (upon success), and x-y domain objects being entered in > the database. This option will only be possible for > corresponding address space which is occupied by a single > inetnum object, to reduce the possibilty of misuse/mistakes. Uhh, ohh, this might be a non-starter (the single inetnum object, not the idea in itself). I like the intent, but again this requires a review of other procedures (or customs) in some places. 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 2

RIPE 34 LIR WG Draft Agenda
by hph＠sys.sol.no 17 Sep '99

17 Sep '99

[ Moderator note: changed local-ir(a)ripe.net -> lir-wg(a)ripe.net ] Dear Working Group Member ! I have put together a first draft of the agenda for the upcoming working group meeting. Please read it carefully and make suggestions for additions and changes. Remember: this is YOUR forum, please send me YOUR suggestions on what you want us to spend time on at the meeting in Amsterdam, Looking forward to meet you there, Hans Petter Holen LIR WG Chair ---------------------------------------------------- RIPE 34 - Local IR Working Group first draft Agenda 1. Admin scribe participant list charter mailinglists 2. Agenda 3. Introduction of the new Registration Services manager, Nurani Nimpuno. meet the RIPE NCC hostmasters 4. RIPE 33 minutes actions 5. Reports from the Registries RIPE APNIC 6. The RIPE community POLICY making process by Mirjam Discussion: is this well understood and 7. ICANN - ASO Current status, Further work Definition of the selection procedure for the address council selection 8. AOB

5 6

RE: RIPE Hostmasters visiting LIRs
by Abbey Shasore 17 Sep '99

17 Sep '99

Hi Chaps, Now come along...it is *great* idea for RIPE to get to know what we do and how we do it. However, I am far from convinced that this is the way to do it! Of course there will be lobbying, of course there will be LIRs that will make an impression, and of course there is a real risk of compromising RIPE neutrality. Also, how would this be funded? Ok for the big(ger) guys, but how about us less big guys? Personally, I would like to have you guys get to know us better and so on - but I am not sure we can afford it! More thought required me thinks... Abbey Shasore A4U Net - Alpha Internet -----Original Message----- From: Sam Critchley [mailto:samc@UU.NET] Sent: 16 September 1999 16:01 To: lir-wg(a)ripe.net Subject: RIPE Hostmasters visiting LIRs Hello, Recently a few colleagues and I have been talking about the way we interact with the people in the RIPE NCC when dealing with customer assignments (and some other matters). One of the things we thought could be beneficial is if Hostmasters had more experience of the kind of issues we in the ISP community face on a day-to-day basis. We thought it might be a good idea if some of the Hostmasters were able to visit an ISP and see how they work, meet the people they deal with and perhaps work alongside them for a period of time. With this in mind we first thought of inviting individual people to come and visit us, or perhaps addressing the NCC asking if this were possible. However, we soon realised that this would have neutrality implications, and that it could be damaging both to the RIPE NCC reputation and to ours, and that for this reason it was unlikely to be accepted by them. In the last week or so I've been in touch with people in several other LIRs here in the Netherlands on an informal basis, and we all seem to agree that, were visits made to multiple registries by multiple members of the staff of the NCC, then this would have fewer neutrality implications. It seems like there are several registries who would be happy to offer help with this if it has a potential benefit for all LIRs. I realise that this has been discussed in various forums before, but feel personally that we are now able to remove many of the barriers which might prevent it happening. Do other LIRs feel that this could be beneficial to everyone in the RIPE community? What do RIPE NCC staff themselves think about it? What kind of restraints do people feel should be placed upon any such scheme? How should it be organised? Should it be discussed at a meeting? Looking forward to any comments on the lir-wg mailing-list, Best wishes, Sam

3 2

COMMENT: "status: LIR-ALLOCATED"
by Berislav Todorovic 16 Sep '99

16 Sep '99

Hello, I'd back the proposal for the "status: LIR-ALLOCATED" attribute, with the possibility to restrict the use of that status to the international LIRs only (or allocations higher or equal to /16) - to avoid possible problems and abuses from small LIRs - intentional or unintentional. 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

Re: RIPE Hostmasters visiting LIRs
by Wilfried Woeber, UniVie/ACOnet 16 Sep '99

16 Sep '99

>Of course we could also try to add a new policy which says that >if a LIR after three warnings from RIPE havn't gotten their >act together they get a RIPE visit, and the full bill for >that visit (the "RIPE-MIB": RIPE-Men In Black :-) Yeah, you fail 3 times to answer a phone call within 30 seconds on Sunday afternoon, and voila, you've got the tax hounds on your neck :-) :-) :-) Reality check, gentlemen! From my point of view there is milage in persuing this idea, with the boundary condition that the goal of this whole exercise is to improve the mutual understanding and information flow between the LIRs and RIR's representatives (i mean: strategically, not for a *particular* LIR or particular HM (or a very small set of both)!). Paying visits to each other is maybe *one* way of achieving that goal. There might be others, quite as well. Let's hear the NCC's point of view on this general idea. Then let's try to sort out the particular goals, boundary conditions, and - eventually - the funding issues. How's that sound? My 2 Groschen (0.02 ATS = 0.00145346 EUR) for X-NCC-RegID: at.aconet Wilfried.

1 0