- lir-wg - mailman.ripe.net

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

New Draft in-addr.arpa Policy Document for Review
by Paul Rendek 10 Jun '02

10 Jun '02

Dear LIRs, We are pleased to announce the availability of the new draft "Reverse Address Delegation Under 'in-addr.arpa' in the RIPE NCC Service Region" document. The draft document can be found in the text to follow and is also available on the RIPE NCC website at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-docume… The deadline for comments and suggestions is Monday, 24 June 2002. After incorporating any suggested changes to the document the final document will be published as a RIPE Document. All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Regards, Paul Rendek RIPE NCC === Draft: Policy for reverse address delegation under in-addr.arpa in the RIPE NCC service region Author(s): Document ID: TBA Date: June 2002 Obsoletes: [insert doc #] Abstract This document describes the policy for reverse delegation of IPv4 assignments and allocations in the RIPE NCC service region. Table of Contents 1.0 Introduction 2.0 Obtaining Delegation of an in-addr.arpa Sub-zone 3.0 Reverse Delegation for Provider Aggregatable (PA) Address Space 4.0 Reverse Delegation for Provider Independent (PI) Address Space 5.0 Duration of the Reverse Delegation 1 Introduction The RIPE NCC provides, as part of its services, the necessary support to enable the reverse resolution of IPv4 addresses into domain names. This service is implemented under the in-addr subdomain described in the "Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain ("arpa")"[RFC3172] document. Delegations for IPv4 addresses contained in allocations made by the RIPE NCC (reverse delegations) are made by the RIPE NCC to the Local Internet Registries (LIRs) and further by the LIRs to ISPs or end users. 2 Obtaining delegation of an in-addr.arpa sub-zone The RIPE NCC will only accept requests for reverse delegation under in-addr.arpa from LIRs. End users must send their requests to the LIR from which they obtained the addresses, or in the case of Provider Independent addresses, to any of the LIRs of their choice.A list of LIRs can be found at: http://www.ripe.net/ripencc/mem-services/general/indices/index.html The procedure for requesting the delegation of zones under in-addr.arpa is published at: http://www.ripe.net/reverse Advice on configuring name servers is available in "Common DNS operational and Configuration Errors" [RFC1912] 3 Reverse delegation for Provider Aggregatable (PA) address space The RIPE NCC accepts requests for reverse delegation solely for address space that has been registered by the LIR as assigned to end users in the RIPE Whois Database. The RIPE NCC will only make delegations on 8-bit boundaries (/16 or /24), though multiple delegations may be requested to cover CIDR blocks bigger than a /24. LIRs should maintain DNS resource records for address space assigned to end users from their own address space, even if the user obtains connectivity from a different LIR. 4 Reverse delegation for Provider Independent (PI) address space The RIPE NCC will reverse delegate a zone of in-addr.arpa to an end user that has been assigned PI space. However, the request must be sent to the RIPE NCC via an LIR, as described above. For delegations of address blocks smaller than a /24 the method described in "Classless IN-ADDR.ARPA delegation"[RFC2317] will be used. 5 Duration of the reverse delegation Provision of reverse delegation services by the RIPE NCC is a membership service. As such, the RIPE NCC will only accept requests for delegation and modifications of delegations from LIRs that are up-to-date with regard to their membership duties. LIRs should provide reverse delegation corresponding to an assignment during the complete validity period of the assignment. -- END

1 0

Re: updating route object
by RIPE NCC Staff 10 Jun '02

10 Jun '02

Dear Arif, The authentication mechanism for routes in RPSL specification is quite different than that of v2 software which we used prior to April 23, 2001. In the new authentication scheme, also the authorisation from aut-num object mentioned in 'origin' attribute of the route must be satisfied. If the authorisation from that aut-num object fails or the aut-num object does not exist, than the creation of the route object is rejected. Please see a graphical representation of this at http://www.ripe.net/ripencc/faq/database/qa4.html#5 Also please see RFC2725, page 36 for this (ftp://ftp.ripe.net/rfc/rfc2725.txt) RIPE Database Reference Manual is available at http://www.ripe.net/ripe/docs/databaseref-manual.html Please contact us at ripe-dbm(a)ripe.net with more details and we will help you to find the solution. Regards, Katie Petrusha _____________________________ RIPE Database Administration. Original message follows: ------------------------ > X-Recipient: <dbint(a)ripe.net> > Delivered-To: lists-lir-wg-out(a)lists.ripe.net > X-Sender: arif.oktay(a)mail.telekom.gov.tr > X-Mailer: QUALCOMM Windows Eudora Version 5.1 > Date: Mon, 10 Jun 2002 11:48:54 +0300 > To: lir-wg(a)ripe.net > From: Arif OKTAY <arif.oktay(a)telekom.gov.tr> > Subject: updating route object > Precedence: bulk > X-Loop-Detect: RIPE NCC > > > Hi, > > I receive following error from db when I try to update a route object. I > provide > proper authorization schema. Can anybody help me about this problem ? > > Regards, > arif > > > Hierarchical authorisation failed, request forwarded to maintainer. > > > > ------------------------ > Arif OKTAY > Tel:+90 312 5551922 > Fax:+90 312 5551959 > ------------------------ > ... > TYLER > And, now it's gone. > JACK > All gone. > --------------------------------------- Fight Club --- -- Shane Kerr RIPE NCC

1 0

updating route object
by Arif OKTAY 10 Jun '02

10 Jun '02

Hi, I receive following error from db when I try to update a route object. I provide proper authorization schema. Can anybody help me about this problem ? Regards, arif Hierarchical authorisation failed, request forwarded to maintainer. ------------------------ Arif OKTAY Tel:+90 312 5551922 Fax:+90 312 5551959 ------------------------ ... TYLER And, now it's gone. JACK All gone. --------------------------------------- Fight Club ---

2 1