June 2002 - lir-wg - mailman.ripe.net

RE: Am I the only one who can't pay their fees ?
by Sweeting, John 13 Jun '02

13 Jun '02

We are having the same problems. -----Original Message----- From: Peter Galbavy [mailto:peter.galbavy@knowtion.net] Sent: Thursday, June 13, 2002 11:26 AM To: lir-wg(a)ripe.net Subject: Am I the only one who can't pay their fees ? I have now faxed my credit card payment form to RIPE on three ocassions to two different numbers and today I get my suspension notice. Am I the only one that appears to be at the sharp end of this potential incompetence or are other having problems with financially sensitive data / faxes going missing at RIPE ? I still think that the focus on non-core activities within RIPE is wrong, and these types of administrative problems only help reinforce my view. rgds, -- Peter Galbavy

2 1

RE: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>For me these two phrases, DELEGATED-TO-LIR and >ASSIGNED-TO-END-USER, hit the spot precisely! >excellent suggestion Guy! >Is it appropriate to request consideration of these terms as replacements >for ASSIGNED and ALLOCATED? Wouldn't it be a good idea to standardize the terminology with ARIN and others? In that case, the term LIR would be considered obscure and meaningless. Since all LIRs are service providers of some sort, either ISPs or an internal network service provider, I think that a standard terminology should try to use generic terms. That would mean either DELEGATED-TO-SVC-PROVIDER or DELEGATED-TO-NSP if you like acronyms (Network Service Provider). In any case, because the distinction between "allocated" and "assigned" has been unclear in the past and because there is a significant shift in terminology from "allocated" to "delegated" this change should be incorporated in an informational RFC. This document would help in clarifying that there is indeed a difference between the two states of an address block and would also help in promoting the use of this terminology amongst the community that deal with IP address delegations and assignments. DELEGATED-TO-NSP and ASSIGNED-TO-USER are two terms that would be clear worldwide. Michael Dillon Network Product Engineering Radianz

3 2

Re: [apnic-talk] Status field for inet6num objects
by Geoff Huston 13 Jun '02

13 Jun '02

>To clarify, the values that APNIC would prefer to use are: > >ALLOCATED PORTABLE >ALLOCATED NON-PORTABLE >ASSIGNED PORTABLE >ASSIGNED NON-PORTABLE > >As I mentioned before, these values would be consistent with those in >IPv4 (which take effect in August when the migration to version 3 of the >RIPE database is complete). > >Comments? I would be in favour of this clarity in the field regarding PORTABLE and NON_PORTABLE. However, the distinction between "ALLOCATED" and "ASSIGNED" is perhaps a bit subtle. regards, Geoff

6 5

Re: [hostmaster-staff] Re: [apnic-talk] Status field for inet6num objects
by Michael.Dillon＠radianz.com 13 Jun '02

13 Jun '02

>Allocation and assign do have definitions - could these be improved >to clarify the meaning? Or does 'delegate' simply convey a much >clearer intention with the address space? Delegation is clearer for two reasons. Firstly, it implies that the the delegator is passing on some responsibility for the address space. The organization receiving a delegation is responsible for managing and administering the addresses. In the case of an assignment, this is less true. For instance, ISPs regularly reassign addresses after a customer disconnects and everyone seems to understand that addresses assignments are controlled by the assigner and can be withdrawn. The second reason has more to do with psychology. Because the terms "allocation" and "assignment" are similar in meaning and visually similar, they are easily confused by a lot of people. They both begin with "a" followed by a double consonant and end with a latin suffix. Of course, clear definitions are always a good thing as well. Michael Dillon Network Product Engineering Radianz

1 0

RE: [apnic-talk] Status field for inet6num objects
by kevin.bates＠bt.com 12 Jun '02

12 Jun '02

seems better but not perfect - the important thing is to get all databases looking the same and using the same terms? strictly speaking it is not "ASSIGNED-TO-END-USER" its "ASSIGNED-TO-SUBNET-USER" for example it could be part of a DHCP dial up pool and thus only " leased" for the duration of that connexion. > At 11:56 AM 6/12/2002, Guy Davies wrote: > >I tend to agree with Nigel, although I'd go for something even > >plainer like DELEGATED-TO-LIR and ASSIGNED-TO-END-USER (I know > >they're a bit verbose but they're absolutely clear ;-) It also makes > >clear that addresses assigned to an LIR in the role of END-USER are > >exactly that. That way, an individual who is struggling with English > >as a second language (or even their first language ;-) can be > >absolutely clear of the status of a range of addresses. > > This is an excellent idea. However I would use > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > That way we clarify the subtle difference while > maintaining consistency with existing documentation. > > (If I remember correctly the term DELEGATED was suggested at the time, > but not used because of its usage in the DNS context as well as > the connotation of total transfer of authority over the resource which > is not quite the case.) > > Daniel

2 1

RE: [apnic-talk] Status field for inet6num objects
by Geoff Huston 12 Jun '02

12 Jun '02

> > This is an excellent idea. However I would use > > ALLOCATED_TO_LIR and ASSIGNED_TO_END_USER. > > That way we clarify the subtle difference while > > maintaining consistency with existing documentation. > > > > (If I remember correctly the term DELEGATED was suggested at the time, > > but not used because of its usage in the DNS context as well as > > the connotation of total transfer of authority over the resource which > > is not quite the case.) To me "DELEGATED-TO-LIR" makes sense, as it infers that the process of further delegation can be used with sub-blocks and/or atomic units can be "ASSIGNED-TO-END-USERs with the inference that no further sub assignments are anticipated. Geoff

1 0

response time for RIPE-NCC-HM-MNT
by Arif OKTAY 12 Jun '02

12 Jun '02

Hi all, I'm waiting for an update via RIPE-NCC-HM-MNT. What's the response time for RIPE-NCC-HM-MNT operations ? Are the requests for this maintainer delivered to the normal hostmaster que or do they have different que and processing order ? I'll be happy if someone can inform me. Regards, arif ao189-ripe ------------------------ Arif OKTAY Tel:+90 312 5551922 Fax:+90 312 5551959 ------------------------ JACK (V.O.) When deep space exploration ramps up, it will be corporations that name everything. The IBM Stellar Sphere. The Philip Morris Galaxy. Planet Starbucks. --------------------------------------- Fight Club ---

2 1

RE: [apnic-talk] Status field for inet6num objects
by Michel Py 12 Jun '02

12 Jun '02

> Anne Lord wrote: > There is no PI in IPv6. > This can't be said often enough. We are working on two new types of v6 addresses that are neither PA nor PI for multihoming. Please keep in mind that PA does not provide enough functionality; if no multihoming protocol is released in a timely manner you will inevitably have PI, or whatever you want to call everyone becoming a LIR. Michel.

1 0

ALLOCATED UNSPECIFIED ???
by Marcus.Ruchti＠colt.de 11 Jun '02

11 Jun '02

Hello, we've problems with creating a route object for the network 193.102.74.0/24. Sony Europe is our customer and told us, this network is their PI space, but the status for the whole IP block is ALLOCATED UNSPECIFIED ! What does this mean an how can I create (or who) a route object for this network ? Thanks, Marcus inetnum: 193.96.0.0 - 193.103.255.255 netname: DE-EUNET-193-96-193-103 descr: ALLOCATED BLOCK descr: Provider Local Registry descr: UUNET/DE country: DE admin-c: HE15-RIPE tech-c: HE15-RIPE status: ALLOCATED UNSPECIFIED notify: robot(a)de.uu.net notify: hostmaster(a)de.uu.net mnt-by: RIPE-NCC-HM-MNT mnt-lower: UUNETDE-I changed: od(a)Germany.EU.net 19970220 changed: od(a)de.uu.net 19971119 changed: hostmaster(a)de.uu.net 19980120 changed: od(a)de.uu.net 19990123 changed: hostmaster(a)ripe.net 19990309 changed: hostmaster(a)ripe.net 19990817 changed: hostmaster(a)ripe.net 19990818 changed: hostmaster(a)ripe.net 20020510 changed: hostmaster(a)ripe.net 20020522 source: RIPE inetnum: 193.102.74.0 - 193.102.74.255 netname: SONY-STC descr: Sony Europe GmbH, STC country: DE admin-c: VM1-RIPE tech-c: PB4313-RIPE tech-c: MV1843-RIPE mnt-by: RIPE-NCC-NONE-MNT changed: ip(a)Germany.EU.net 19940726 changed: mn(a)Germany.EU.net 19940802 changed: ripe-dbm(a)ripe.net 19990706 changed: ripe-dbm(a)ripe.net 20000225 source: RIPE route: 193.96.0.0/13 descr: UUNETDE-AGG-193.96 origin: AS702 member-of: RS-UUNETEUDE mnt-by: UUNET-MNT changed: mz(a)de.uu.net 20011123 source: RIPE

5 4

COLT Telecom and the RIPE DB copyright
by Alexander Bochmann 10 Jun '02

10 Jun '02

Hi, today we received two mailings from COLT Telekom, addressed to "2i Distribution & Solution, Offenburg" and "2i Distribution & Solution, Loerrach und Waldshut" We changed our company name about 4 years ago, and these two strings do only appear in the RIPE database for two old networks we previously used as XLINK PoP. I have heard from others (and from some of our customers) that they got the same mailing, also destined to addresses that have obviously been retrieved from the RIPE DB (the content of the mailing is targeted to KPNQwest Germany customers who are urged to change to COLT). I think the RIPE DB copyright is quite clear on the use of it's data for advertizing purposes. Yet I never heard of an occasion where RIPE actively enforced the copyright. Nevertheless, this seems to be a case of a quite wide spread abuse - anybode else here who recieved this or a similar mailing from COLT and would like to see RIPE take action? Regards, A. Bochmann

3 2