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

Draft minutes from lir-wg at RIPE 41
by Hans Petter Holen 10 Sep '02

10 Sep '02

Dear WG, The RIPE NCC have just finished the draft minutes and published them on the RIPE web site under: http://www.ripe.net/ripe/wg/lir/r41-minutes.html RIPE Meeting: 41 Working Group: LIR Status: 1st Draft Revision Number: 1 Please mail comments/suggestions on: content to the Chair of the working group. format to webmaster(a)ripe.net. ---------------------------------------------------------------------------- --- Draft Minutes of the LIR Working Group session of the RIPE 41 Meeting 14-18 January 2002, at the Krasnapolsky Hotel, Amsterdam, Netherlands. ----------------------------------- Chair: James Aldridge Vice-Chair: Denesh Bhabuta Scribe: Jeannette Decades ----------------------------------- Agenda: A. Admin - scribe, participant list, charter, mailing-lists B. Agenda bashing C. RIPE 39+40 (minutes & actions) D. Report from the RIPE NCC Hostmasters E. RIPE 185 ("European Internet Registry Policies and Procedures") F. Change of policy for Portable address space G. RFC 2050 ("European Internet Registry Policies and Procedures") revision H. Report from The Address Council Y. Any Other Business Z. Open Microphone. Denesh Bhabuta (DB): Hans Petter Holen couldn't make it. So the meeting will have to do with James Aldridge and myself, Denesh Bhabuta. We want to set a ground rule: One of the complaints from the past was that the LIR WG has been fed with too many discussions. Discussions are supposed to happen on the mailing lists and policy decisions are to be made at the meeting. James Aldridge (JA): The agenda was sent out yesterday to the mailing list. ======================== A: Scribe. ======================== DB: Could we have a non-RIPE staff scribe please? No reactions. A RIPE staff member is scribe. ======================== B: Agenda bashing ======================== JA: Are there any additional items for the agenda? No reactions. ======================== C: RIPE 39 and RIPE 40 minutes and actions. ======================== JA: The minutes are on the website since November we think. Actions as it appears on the website, few of them are very old actions from RIPE 35, 36 and 38. Most of these had something happened since the last RIPE meeting. A lot of it is ongoing work. The 38.5 LIR-Allocated, my original suggestion, is now LIR-Partitioned and some email is sent out this week. It is now in the test database and will go live real soon now. Working group chair roles is working fine since Hans Petter Holen is not here and I am. Policy action undivided address space action on the working group to participate on the RFC 2050 is in progress. ======================= D: Report from the RIPE NCC Hostmasters ======================== Presentation of Sabrina Waschke can be found at: http://www.ripe.net/ripe/meetings/archive/ripe-41/presentations/lir-rsreport /index.html Some additional comments from Sabrina on the slides: RS staffing. We have now 5 teams. Three new hostmasters are starting in January. At this point we hope to be fully staffed and can cope with the workload. And as you can see, you have probably seen it before, we also work on future growth. (Sabrina shows her big belly). Number of requests in hostmaster(a)ripe.net. In 2000, we see a peak but now the graph shows a steady growth. We introduced last year the two-day-turnaround time for ongoing tickets. That meant that when your request was picked up out of the wait queue, a hostmaster dealt with it, you replied, you had to wait for 48 hours before you got a response from us again. That means that correctly filled out requests get a faster approval. The special lir-help(a)ripe.net mailbox is not holding up normal requests anymore. We still apply the 'approve but educate' approach. Even not perfect requests got approved and we gave tips and information for improvements to get a faster approval next time. Wait queue. The last 6 months the wait queue is low. The last 2 months it is a bit higher, due to Dutch weather (sickness) and Christmas holidays. Total LIRs per region. The growth is slowing down. We don't expect too many new LIRs. IPv4 Allocation distribution. LIRs that are working all over Europe have the country code EU. Policy development. A message was sent out to the LIR WG concerning the /20 criteria. At RIPE 40 the decision about the Assignment Window (AW) for infrastructure for LIRs was decided upon and it was introduced in December 2001. Already 250 objects have been created in the database with the INFRA-AW extension. Not all of them are valid. Some LIRs have tried to use this to clean up the database. RS services are working on a document that tries to cover everything concerning mergers, take-overs and closures of LIRs. IPv6. The assignments for Exchange Points have been introduced in August 2001. E: RIPE 185 ("European Internet Registry Policies and Procedures") ======================== Nurani Nimpuno (NN): We encourage everyone to look at the document and to give comments. We're speaking about the new policy draft document for IPv4 policies. The document has been out on the web for 5 months and there was very little activity. The couple of comments that have been made have been published on the LIR WG mailing list. JA: I'm not sure how much more we can do. There hasn't been very much discussion on the mailing list about this. My opinion is this, more profitable work is done on the mailing list. Then we can come to the RIPE meetings for final decisions, rather than having long drawn-out arguments and conversations here. But are there any brief comments from anyone here? Because we're actually ahead of schedule and I'm trying to think of anything to fit in a bit of time. I encourage everyone to join the mailing list and to participate in the revision process. The email address is ripe-185bis(a)ripe.net. ======================== F: Change of policy for Portable address space ======================== JA: The question is if people are happy with the new policy? No reaction. DB: Are people aware of the policy change? It's about the requirements of a /22 immediate or the previously use of a /22 to become a new LIR. This was voted on at the last RIPE meeting. Any thoughts? Are people finding it difficult with their customers who want to be mainly multi-homed? Comments? No? We will continue this discussion on the mailing list. ======================== G: RFC 2050 ("European Internet Registry Policies and Procedures") revision ======================== JA: The agenda on the web was wrong about this one. This should be the RFC 2050, the global Internet Registries guidelines, which is being revised and prolong sides the European policy. Again joining the mailing list for participation and discussion is appreciated. Are there any comments for now? Mark Mcfadden (mcf(a)uwm.edu) I'll give a brief update. There is a mailing list available through ARIN for the global RFC 2050 discussion. Part of that working group, there are also some milestones. We're a little bit behind on those because of some things that happened at the end of last year. But we can start see there again is some movement forward. So I encourage anyone who is interested in the discussion of the revision of RFC 2050 to make sure that you're part of that mailing list. Mailing list address: rfc2050-WG(a)arin.net JA: Any questions, comments, anything? Comment from ?: I think that there are more hostmasters here are than LIRs. ======================== H: Report from The Address Council ======================== Barbara Roseman gave a report from the Address Council. Slides can be found at: ======================== Y: Any Other Business ======================== UUNET: There has been a discussion on the mailing list about PI - multihomed issues. The question raised if multi-homed is always needed or not. We have customers that need multi-homing. But not all providers will route small address blocks. JA: I don't know if there's anything that the LIR WG can do to force providers to route any particular address space. I would be inclined, rather than a policy change our of LIRs, have the Routing WG work on this issue and come up with a 'best practice or something'. DB: We can talkabout 'best practice' but there are commercial realities behind this as well. A lot of ISPs have customer requirements to fulfill. You're not the only person who has spoken about this issue with us and it has mainly come up since the last policy change. This was about the minimum requirement of a /22 before we can get address space. Are there any suggestions? UUNET: As far as I can see, the company that I work for, which is UUNET, is thinking about(at least the hostmaster is, which I am not) having a policy where you accept other provider's PA space instead of trying to go the PI route. This is current thinking, this is no decision, but the problem is we don't have a consistent policy across our AS and we'd like to implement one. Before we implement it we'd like to have consistent policy within RIPE. The problem is that whenever we get the discussion, everybody starts jumping and shouting saying: "Multi-homing". Then the discussion dies because multi-homing is the issue. But before we solve that problem we would like to have something implemented that is workable right now instead of waiting until we solve the mult-homing discussion, which seems to be without a logical solution. DB: My suggestion is that we take this up with the Routing WG as well and maybe we can make this into an action item from this meeting. UUNET: I didn't raise it in the Routing WG yesterday, thinking that was more appropriate to the LIR WG. I guess there were some initiatives in the community, but they all died. So I wonder if there's anybody else that feels like this, something we need to resolve rather sooner than later. DB: Any other comments? No reaction. UUNET: I guess there's too much RIPE NCC people here as previously discussed. DB: We'll set it as an action point. JA: This is the first new action point from this RIPE meeting. Any other questions, comments? I think this is about it for this morning. Please participate on the mailing lists. It does make it so much easier if there's been discussion before RIPE meetings. We can then reach final decisions at these WG-meetings.

2 1

Status field for inet6num objects
by Joao Luis Silva Damas 08 Jul '02

08 Jul '02

[** Mail posted to both APNIC and RIPE lists in the hopes of trying to find a solution suitable for all users of RIPE or RIPE-derived software **] Dear all, the inet6num, like the inetnum object, has a field named "status" which stores some information about the nature or position of a block of addresses in the delegation chain, from the RIR through to the end user. Currently, the status field for inet6num object is generated by the Database software based on the size of the address block and its possible values are: o TLA o SubTLA o NLA o SLA This notation has been deprecated and it is time to adapt the database. Discussions on this matter have identified the usefulness of having the capability to distinguish between allocations made by the RIR, allocations made by an LIR or their customers and assignments to end users. As such, we propose to modify the "status" attribute of the inet6num object to be: a) not-generated. This means users must assign a value to the status attribute when creating the object, just as in the inetnum object b) have the following possible values: RIR-allocated LIR-allocated Assigned to be used according to the following set of rules: The RIR-allocated status can only be used in objects representing allocations created directly by the RIR. The LIR-allocated status can be used by LIRs and their customers to represent blocks of addresses that are not assigned to specific end users. There can be several levels of objects with this status. The Assigned status must be used in objects representing assignments to end users (households, companies, enterprises, etc) We hope that with this modification the information in the Database will more accurately describe the registration of IPv6 address space. A possible transition to the new values could be: 1) RIRs modify status fields for allocations 2) Any new objects and modifications to existing ones must have a value for the status field corresponding to the ones described above. Otherwise the update will fail. 3) RIRs contact LIRs to have the status of assignments and sub-allocations updated. Best regards, Joao Damas RIPE NCC

6 8

Re: [lir-wg] New Draft in-addr.arpa Policy Document - Reminder
by Janos Zsako 28 Jun '02

28 Jun '02

> From owner-lir-wg(a)ripe.net Thu Jun 20 12:15:28 2002 > From: Paul Rendek <ncc(a)ripe.net> Dear all, > This is a reminder that the deadline for comments and suggestions for the > draft in-addr policy document is set for Monday, 24 June 2002. The new > draft "Reverse Address Delegation Under 'in-addr.arpa' in the RIPE NCC > Service Region" document can be found on our website at: > > http://www.ripe.net/ripencc/mem-services/registration/policies/draft-docume… > > All comments and suggestions should be sent to <lir-wg(a)ripe.net>. I would have a short question and a suggestion for clarification. 1. Is the last paragraph of 3.0 not superfluous in the light of the last paragraph of 5.0? 3.0: "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." 5.0: "LIRs should provide reverse delegation corresponding to an assignment during the complete validity period of the assignment." I mean that my understanding is that for 3.0 there are two cases: the end-user either _changes_ its provider, in which case they will have to renumber, and during renumbering their assignment is valid, i.e. the old LIR has to provide reverse DNS according to 5.0 during renumbering, or the end-user becomes multi-homed, therefore they will keep the old address space for which they obviously will need reverse DNS (on the long run) that the old LIR is again supposed to provide, based on 5.0. Am I missing something? 2. I think the intent of first paragraph of 3.0 is to accept a reverse delegation of an address block as soon as there is ANY address space assigned from it (i.e not ALL has to be assigned prior to reverse delegation), assuming that the whole block has been allocated to that LIR (this is relevant only for /16s). Therfore I suggest something like: "The RIPE NCC accepts requests for reverse delegation solely for address space that HAD BEEN ALLOCATED TO THE REQUESTING LIR AND AT LEAST ONE PORTION OF WHICH has been registered by the LIR as assigned to End Users in the RIPE Whois Database." (You will probably find a better word than "portion" to describe this). Best regards, Janos

2 1

New IPv6 Documents available
by RIPE NCC Document Announcement Service 27 Jun '02

27 Jun '02

New/Revised RIPE Document Announcement, apologies for multiple e-mails. -------------------------------------- Revised/new documents available from the RIPE document store. Ref: ripe-246 Title: IPv6 Address Allocation and Assignment Policy Author: ARIN, APNIC, RIPE NCC Date: 27 June 2002 Format: PS= 812450 TXT=31632 Obsoletes: ripe-196 Ref: ripe-247 Title: Initial IPv6 Allocation Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=16615 TXT=4226 Obsoletes: ripe-195 Ref: ripe-248 Title: Supporting Notes to the Initial IPv6 Allocation Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=28439 TXT=12788 Ref: ripe-249 Title: IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=16477 TXT=4126 Ref: ripe-250 Title: Supporting Notes for the IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region Author: Leo Vegoda Date: 27 June 2002 Format: PS=34008 TXT=15211 Short content description ------------------------- This set of IPv6 documents define registry policies for the assignment and allocation of globally-unique IPv6 addresses to Internet ServiceProviders (ISPs) and other organisations. The core document: "IPv6 Address Allocation and Assignment Policy" (ripe-246) obsoletes the "Provisional IPv6 assignment and allocation policy document" (ripe-196). It was developed through joint discussions among the APNIC, ARIN and RIPE communities. The other documents support the policy document, and provide Local Internet Registries with request forms for IPv6 address space. Supporting notes for the request forms can be found in the supporting notes documents. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via WWW at the following URLs: "IPv6 Address Allocation and Assignment Policy" (ripe-246) is available at: http://www.ripe.net/ripe/docs/ipv6policy.html "Initial IPv6 Allocation Request Form in the RIPE NCC Service Region" (ripe-247) is available at: http://www.ripe.net/ripe/docs/ipv6-initial.html "Supporting Notes for the Initial IPv6 Allocation Request Form in the RIPE NCC Service Region" (ripe-248) is available at: http://www.ripe.net/ripe/docs/ipv6-supp-initial.html "IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region" (ripe-249) is available at: http://www.ripe.net/ripe/docs/ipv6-assignment-request.html "Supporting Notes for the IPv6 End User Site Assignment Request Form in the RIPE NCC Service Region" (ripe-250) is available at: http://www.ripe.net/ripe/docs/ipv6-supp-assignment.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-246.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-246.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-247.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-247.txt plain text version Kind Regards, RIPE NCC Document Announcement Service

1 0

New Draft in-addr.arpa Policy Document - Reminder
by Paul Rendek 20 Jun '02

20 Jun '02

Dear Colleagues, This is a reminder that the deadline for comments and suggestions for the draft in-addr policy document is set for Monday, 24 June 2002. The new draft "Reverse Address Delegation Under 'in-addr.arpa' in the RIPE NCC Service Region" document can be found on our website at: http://www.ripe.net/ripencc/mem-services/registration/policies/draft-docume… All comments and suggestions should be sent to <lir-wg(a)ripe.net>. Regards, Paul Rendek RIPE NCC

3 2

RE: [apnic-talk] Status field for inet6num objects
by Guy Davies 20 Jun '02

20 Jun '02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > -----Original Message----- > From: Nigel Titley [mailto:nigel@titley.com] > > On Wed, 2002-06-12 at 07:11, Daniel Karrenberg wrote: > > At 06:00 AM 6/12/2002, Geoff Huston wrote: > > >However, the distinction between "ALLOCATED" and > "ASSIGNED" is perhaps a bit subtle. > > > > When these attributes were created, those particular words > were in deemed both descriptive and clear. > > Maybe the language concerned has shifted underneath in the > meantime ;-). > > As a native speaker of one of its dialects, would you make > a suggestion for improvement? > > Well actually as a native speaker of (another) of its dialects, > I've never considered the distinction of ALLOCATED and ASSIGNED to > be other than subtle. I'd much prefer DELEGATED and ASSIGNED or > some such. This may be a matter of taste however. 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. Just my two pence... Regards, Guy -----BEGIN PGP SIGNATURE----- Version: PGP 7.0.1 iQA/AwUBPQca4I3dwu/Ss2PCEQJv6ACeMa1ZbnoN3P7r6VaBANGPa1yXN9UAoMLQ cJpgKn6FvDPmyD1X02WLXJF3 =yl1x -----END PGP SIGNATURE----- This e-mail is private and may be confidential and is for the intended recipient only. If misdirected, please notify us by telephone and confirm that it has been deleted from your system and any copies destroyed. If you are not the intended recipient you are strictly prohibited from using, printing, copying, distributing or disseminating this e-mail or any information contained in it. We use reasonable endeavors to virus scan all e-mails leaving the Company but no warranty is given that this e-mail and any attachments are virus free. You should undertake your own virus checking. The right to monitor e-mail communications through our network is reserved by us.

9 11

Wait Queue
by Tanya Hinman 18 Jun '02

18 Jun '02

Why is the wait queue even longer than it was before the last RIPE Meeting? I thought the general consensus was to get the waiting issue resolved??? 24 days for an ASN request is a bit long. Tanya

2 1

New Document available: RIPE-234
by RIPE NCC Document Announcement Service 17 Jun '02

17 Jun '02

New/Revised RIPE Document Announcement -------------------------------------- A set of new documents is available from the RIPE Document Store: IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region (ripe-234) IPv4 First Allocation Request Form (ripe-235) Supporting Notes for the IPv4 First Allocation Request Form (ripe-236) New Values of the "status:" Attribute for Inetnum Objects (LIR-PARTITIONED) (ripe-239) IPv4 Additional Allocation Request Form (ripe-240) Mergers, Acquisitions, Takeovers and Closures of Organisations Operating an LIR (ripe-241) Autonomous System (AS) Number Assignment Policies and Procedures (ripe-245) Short content description ------------------------- This set of IPv4 policy documents replaces the now obsolete ripe-185 (European Internet Registry Policies and Procedures). Additionally, we have created specific forms for Local Internet Registries to request a first allocation and additional allocations. Accessing the RIPE document store --------------------------------- All documents are on-line at the following URLs: http://www.ripe.net/ripe/docs/ipv4-policies.html http://www.ripe.net/ripe/docs/first-allocation.html http://www.ripe.net/ripe/docs/first-allocation-support.html http://www.ripe.net/ripe/docs/lir-partitioned.html http://www.ripe.net/ripe/docs/add-allocation.html http://www.ripe.net/ripe/docs/mergers.html http://www.ripe.net/ripe/docs/asn-assignment.html The RIPE document store is also available via anonymous FTP to ftp.ripe.net, in the directory ripe/docs/. The URLs for the new documents on the FTP-server are: ftp://ftp.ripe.net/ripe/docs/ripe-234.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-234.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-235.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-235.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-236.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-236.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-239.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-239.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-240.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-240.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-241.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-241.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-245.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-245.txt plain text version Kind Regards, RIPE NCC Document Announcement Service

2 1

Concerns about billing procedures at RIPE NCC
by Axel Pawlik 14 Jun '02

14 Jun '02

Dear all, regarding today's concern about billing at the RIPE NCC, and the related procedures, I have spent some time this afternoon to look into the matter. What I have found gives not raise to concern about procedures, or the privacy of member's data at the RIPE NCC. It might be possible, though, to remove some slack from the timeline of the payment process. It is our goal to make administrative procedures as efficient and inobtrusive as possible. To assist us in this undertaking, please ensure that your billing data you send is as complete as possible. Should you have any questions or concerns in this aspect, do not hesitate to contact either me, or the RIPE NCC's controller, Jochem de Ruig (jochem(a)ripe.net) directly. kind regards, Axel Pawlik Managing Director, RIPE NCC

1 0

Am I the only one who can't pay their fees ?
by Peter Galbavy 14 Jun '02

14 Jun '02

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

3 7

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

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

Re: KPNQwest ns.eu.net server.
by Steven M. Bellovin 07 Jun '02

07 Jun '02

In message <200206061624.40230.dani(a)intelideas.com>, Daniel Concepcion writes: > >Yes Neil, > >It should be interesting to know the 'official' requirements/recommendations >for ccTLD's hosting >For example: diversity geographical, network needs, security needs, building >environment., etc > I don't know of any official requirements. But RFCs 2182 and 2870 offer good guidance. (Some of 2870 is root zone-specific, but most of it would apply to a ccTLD server.) --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com ("Firewalls" book)

5 8

Re: Re: Re: KPNQwest ns.eu.net server.
by Sabine Dolderer/Denic 07 Jun '02

07 Jun '02

Hello Arnold, On 06.06.2002 16:55 Arnold Nipper <arnold(a)nipper.de> wrote: > > On Thu, Jun 06, 2002 at 04:31:21PM +0200, Daniel Concepcion wrote: > > > > > > Yes, but there is problem about the transit for the network of the IXP > > In my experience, some big providers only have the commercial view of > > internet. > > If an IXP decides to offer infrastructural services then you have to buy > upstream of course. > > > Really, if all the IXP members give some transit to the IXP for essential > > services, internet will be more robust. > > > > At least each IXP member would have direct connectivity to such > infrastructural services (DNS, NTP, WHOIS, NNTP??) and thereby their > customers would benefit from it. I agree that IXPs would be very gould locations as they offer network diversity, but there is one question still open and that is who will be the one running the and monitoring the server. And we at DENIC have seen in the last years an increasing demand in running the servics by ourself as only then we have the complete control and information about statistics, network attacks, performance ... There is a project within CENTR where we try to share secondary services on one host with the advantage for all geting these informations. (And yes we are still working to connect to DECIX ;-) ) Sabine > > And an IXP should be in a good position to get upstream :-)) And for > the commercials: these services are not for free of course. So bills > for IXP members will drop not raise. > > > -- Arnold > > -- Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

2 1