January 2003 - lir-wg - mailman.ripe.net

Short Address Council update
by Hans Petter Holen 08 Feb '03

08 Feb '03

Dear wg, Just to give you a short update after the Address Council phone meeting last night. As last years AC chair Barbara Rosseman have now left the address council and started working for ICANN our communication channels towards ICANN should be even better than ever. (With both John Crain and Barbara among ICANN staff). Accoding to our internal procedures we had an election for AC chair and after due discussion and election Mark McFadden was elected as AC Chair and Hartmut Glaser and myself co-chairs. As a consequence of the ICANN reform the AC is supposed to appoint a representative on the ICANN nomination committee. The role of the nomcom is to elect some of the future ICANN board members. (The AC still has a task to elect some). Our long term goal is to establish an open and transparent process for this election, just as the ICANN board member elections of the past, but with the given time frames (the nomcom will start its initial work close to february 1st) the AC will elect a representative to the nomcom. Since I am on the AC to serve the RIPE NCC community and the best interest of the internet community, please feel free to give me or other AC-coord representatives input with respect to particular nominations as soon as possible. -hph

1 1

Spam on mailing list
by RIPE NCC WebMaster 30 Jan '03

30 Jan '03

Dear all, Apologies for forwarding some spam to the lir-wg mailing list. This was purely a human error on my account. Sorry for the inconvenience, Regards Jeroen Bet RIPE NCC Mailing list moderator ==================

1 0

Draft: IPv4 Sub-allocations - revisited
by Sascha Lenz 24 Jan '03

24 Jan '03

Hay, even though i hope that everyone already noticed it, i didn't see any comments about it on any list yet: in "3.0 Database registration" the draft states: [...] 3.1 Status attribute for inetnums representing sub-allocations Registration of a sub-allocation in the RIPE Database requires the creation of an inetnum object with an appropriate status value. 3.2 Restriction on creation of inetnums with an .ASSIGNED. status The creation of an inetnum object with a status of .ASSIGNED PA. or .ASSIGNED PI. will not be allowed if there is either a less specific or more specific inetnum object with an .ASSIGNED. status. The assigned status inetnum is the most specific registration allowed. [...] ...just that it seems to lack the information _what_ status value is appropriate for a sub-allocation then. One might guess that "LIR-PARTITIONED [PA|PI]" could be meant, but it also might be something completely different or even some new value since the current ripe-239 doesn't really cover the usage the sub-allocation draft suggest (5.0 in ripe-239 "IP Address Policy Implications"). ...just my 0.02EUR -- ========================================================================== = Sascha 'master' Lenz SLZ-RIPE slz(a)baycix.de = = NOC BayCIX GmbH = = http://www.noc.baycix.de/ * PGP public Key on demand * = ==========================================================================

3 5

draft-documents: sub-allocations.html
by Christoph Mohr 23 Jan '03

23 Jan '03

Dear Colleagues! Referring to http://www.ripe.net/ripe/draft-documents/sub-allocations.html, I found a problem which maybe will arise after publishing the document. In 3.2 Restriction on creation of inetnums with an "ASSIGNED" status I read: The creation of an inetnum object with a status of "ASSIGNED PA" or "ASSIGNED PI" will not be allowed if there is either a less specific or more specific inetnum object with an "ASSIGNED" status. The assigned status inetnum is the most specific registration allowed. Now the question I have is if this will apply to all inetnum objects which are already in the database. We, the Academic Network of the Federal State of Baden-Wuerttemberg (BELWUE), manage the internet not only for the universities in Baden-Wuerttemberg, but as well for many public schools. To provide public schools with internet addresses, we are allowed by the universities to use some of the addresses in their own class B network they don't need. (I think there won't be one university which currently uses all their IPv4 addresses in its B block.) So we are able to economise IPv4 resources by using IP addresses which wouldn't be used otherwise. That's why there are overlapping inetnum objects which are both "ASSIGNED PI", which will be forbidden in the future if I understand well the new document. Example: Within 132.230/16 which is FDN (Freiburg University) one can find 132.230.194.0 - 132.230.196.255 (BELWUE-SCHULEN) which are IP addresses of public schools in the Freiburg region. We prefer to have this inetnum object because we don't want the university to deal with abuse mails which may occur because there isn't always specialised staff in the schools to manage firewalls, mailservers etc. correctly. When there is an abuse incident we are able to react quickly by contacting the respective school. We made yet the experience that these entries in the database were very useful. Well, perhaps I misunderstood the draft document and there won't be any problems like the one I mentioned. Anyway, there should be some clarification about the objects the database won't allow to create in the future. Best regards, Christoph Mohr -- -- Christoph Mohr, BelWue Coordination ---------- mailto:mohr@belwue.de ----- Computing Center University of Stuttgart (RUS) Phone: +49 711 685-2079 Allmandring 30, D-70550 Stuttgart Fax: +49 711 678-8363 ------------------------------------------------- http://www.belwue.de/ -----

4 7

New Documents available: RIPE-263, RIPE-267
by RIPE NCC Document Announcement Service 22 Jan '03

22 Jan '03

New RIPE Documents Announcement -------------------------------------- Two new documents are available from the RIPE document store. Ref: ripe-263 Title: Autonomous System (AS) Number Assignment Policies and Procedures Author: Mirjam Kuehne, Nurani Nimpuno, Sabrina Wilmot Date: 22 January 2003 Format: PS=16292 TXT=6248 Obsoletes: ripe-185, ripe-245 Obsoleted by: Updates: Updated by: Ref: ripe-267 Title: IPv6 Address Allocation and Assignment Policy Author: ARIN, APNIC, RIPE NCC Date: 22 January 2003 Format: PS=816883 TXT=34295 Obsoletes: ripe-196, ripe-246 Obsoleted by: Updates: Updated by: Short content description ------------------------- The "Autonomous System (AS) Number Assignment Policies and Procedures" provides a description of Autonomous System Numbers, their assignment procedures and guidelines on how to obtain them in RIPE NCC service region. "Assignments for Internet Experiments" has been included in this latest version. The "IPv6 Address Allocation and Assignment Policy" defines registry policies for the assignment and allocation of globally unique IPv6 addresses to Internet Service Providers (ISPs) and other organisations. "Assignments for Internet Experiments" has been included in this latest version. Accessing the RIPE document store --------------------------------- You can access the RIPE documents in HTML format via our website at the following URLs:. http://www.ripe.net/ripe/docs/asn-assignment.html http://www.ripe.net/ripe/docs/ipv6policy.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-263.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-263.txt plain text version ftp://ftp.ripe.net/ripe/docs/ripe-267.ps PostScript version ftp://ftp.ripe.net/ripe/docs/ripe-267.txt plain text version

1 0

Registration Services: Summary 2002
by leo vegoda 20 Jan '03

20 Jan '03

Dear Colleagues, Over 2002 the RIPE NCC has worked to improve the quality of Registration Services. Notable improvements, additions and changes include: - Response times to new tickets have improved dramatically, being answered within one working day. Since September the time taken to a first response has never risen above two working days. This is despite a record high number of tickets being received in October 2002. - The LIR WG approved new policy documents. The new structure makes documents easier to read and maintain. We will continue efforts to make policy documents clearer. - The common IPv6 policy has been implemented and we have made 76 new allocations under it. - The LIR WG reviewed the ASN assignment policy immediately before and during RIPE 43 in Rhodes. No major changes were made. - The RIPE NCC worked with Gert Döring to analyse issues that need to be addressed in a proposal for a sub-allocation policy. Gert's proposal was accepted and a draft document is now under review by the LIR WG. <http://www.ripe.net/ripe/draft-documents/sub-allocations.html> - New LIRs can now take up membership much faster than in the past. The procedure has been streamlined and better documented. - Attendees at RIPE 43 in Rhodes have tested a new way to access RIPE NCC services. The "LIR Portal" was launched today as an official service and is accessible to all members. - A policy allowing temporary assignments of Internet resources for Internet experiments has been implemented. The policy wording will be incorporated into the IPv4, IPv6 and ASN policy documents. This is in addition to the existing procedure for temporary assignments to conferences and trade fairs. - We have completed the transfer of ASN registrations from the ARIN Database to the RIPE Database and have run a trial for the transfer of IPv4 registrations. In addition to this work we have plans to improve the quality of the RIPE NCC's Registration Services over 2003: - The "Hostmaster Robot" will be replaced with a new system that will handle a revised set of simpler forms. - We are reviewing the status attribute values for inetnum objects in the RIPE Database. - An improved tool to replace "asused_public" will be released soon. - A formal explanation of the system used to determine Assignment Windows will be published. - Customer service will be improved by having Hostmasters call customers to resolve difficult or complex requests more quickly. Kind regards, -- leo vegoda RIPE NCC Registration Services

2 1

Results of RIPE NCC 2002 Membership Survey
by Axel Pawlik 20 Jan '03

20 Jan '03

Dear Colleagues, As you are aware, the RIPE NCC commissioned KPMG to carry out a members and stakeholders survey on its behalf from 29 August to 31 October 2002. The focus of the survey was to give the membership and stakeholders a formal opportunity to voice opinions on the services provided by the RIPE NCC, and to give constructive input needed to plan services for the future. The survey included e-mailed responses and face-to-face meetings. There were a total of 285 respondents. The results of the survey, in full and abridged versions, are now available and can be found at: http://ripe.net/survey2002/results/ I wish to thank the members of the community who provided valuable feedback. I look forward to discussing the survey and results at the upcoming RIPE Meeting here in Amsterdam next week during Thursday's plenary session. I also wish to thank KPMG for conducting a professional and insightful analysis of our membership. Regards, Axel Pawlik RIPE NCC

1 0

New service: The RIPE NCC LIR Portal
by Axel Pawlik 20 Jan '03

20 Jan '03

Dear Colleagues, The RIPE NCC announces the release of the RIPE NCC LIR Portal. This new service will help reduce delays by providing LIRs increased access to the RIPE NCC via a web interface. The beta testing of this service started at RIPE 43 in September 2002. In addition to managing registry data, LIRs will be able to make other queries and updates without going through the RIPE NCC staff. Once the user is authenticated to the system, they will be able to access LIR specific resources and all information exchanged will be encrypted to ensure security. Features of the RIPE NCC LIR Portal include: - viewing and editing of LIR contact and address information - viewing of billing information - viewing of IP and AS resources - viewing status of open tickets - news and events To activate your account, please follow the procedure found at: https://lirportal.ripe.net/lirportal/activation/activation_request.html Or you can activate your account at the Hostmaster Centre at RIPE 44 with a photo ID. Any problems or suggestions can also be shared at the Hostmaster Centre. New features of the portal will be added based on response from the community. We welcome feedback on this new service. Comments can be sent to <lirportal-feedback(a)ripe.net>. Regards, Axel Pawlik RIPE NCC

1 0

Updated proposal for clean-up of references by name
by Engin Gunduz 16 Jan '03

16 Jan '03

[Apologies for duplicate messages] Dear Colleagues, I'm attaching the updated proposal for automatically cleaning up the references by name in RIPE Whois Database. We have incorporated Janos's suggestions to the proposal. If no more comments come, we plan to apply the procedure described in the proposal in the first half of January, 2003. The operation should not take more than a day. We will notify the community about the actual date of the operation. Regards, Engin Gunduz ____________________________ RIPE NCC Database Group -------------- Proposed solution for cleaning up references by name and other invalid references in RIPE Whois Database Motivation: References by name and invalid references cause two main problems: 1. One reference by name in a single object locks all person and role objects with that name, that is, they cannot be deleted, because of referential integrity checks. 2. Having anything other than a NIC handle as a reference makes the implementation of whois database software considerably more complex, since the software needs to deal with these exceptions. This increases the coding time, maintenance time and testing time of the software. Classification of the inconsistencies we need to solve and proposed solutions: 1. Objects that refer to a person or role object by name. a. There is only one object with this name. 1. The referring inconsistent object is not maintained, or the maintainers of referring inconsistent object and the person/role object with this name are the same. Solution: Update the referring inconsistent object so that it will contain the NIC handle instead of the name. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. The referring object is maintained, and the maintainers are different from the maintainers of the object with the referred name (If the latter object is not maintained, then the maintainers are by definition different.) Solution: Create a role object with this name. It will list the role or person object with this name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. b. There is no person or role object with this name: Solution: Create a person object with this name. Clearly mark this new object putting appropriate remarks attributes so that users will see it is actually a dummy object. Update the inconsistent object to refer to the NIC handle of this new person object. Add appropriate remarks and changed attributes to the object to explain the reason for update. Protect it with the inconsistent object's maintainer(s). c. There are multiple person and role objects with this name. Solution: Create a role object with this name. It will list all the other role and person objects with the same name in its admin-c and tech-c attributes. Update the inconsistent object to refer to the NIC handle of this new role object. Add appropriate remarks and changed attributes to the object to explain the reason for update. 2. Objects that refer to a non-existent NIC handle. Solution: Create a person object with that NIC handle. Clearly mark this new object so that users will see it is actually a dummy object. Name it "person: Place Holder Object". Protect it with the inconsistent object's maintainer(s). Note that there is no need to update the inconsistent object itself. 3. Objects that refer to a string which is neither a name, nor a NIC handle. For example, it might be a phone number in admin-c attribute, or it might be 'Gunduz', a string that can't be a NIC handle, as it's longer than 4 letters, nor can it be a name as it has only one word. Another example could be "Mr. Gunduz", which enters this category because "Mr" can't appear in a name of person/role object. Solution: Create a person object for each such reference. Name the object "person: Place Holder Object" and list the object that refers to it in its remarks attribute. Protect it with inconsistent object's maintainer(s). Then update the inconsistent object to refer to the NIC handle of this new place holder person object. In each case an object is updated, or created, send appropriate notifications (determined by "mnt-by" and "notify" attributes, as with all other updates). Please note that this proposal does not actually solve the problem of invalid contact information-- rather, it makes the data set more uniform, thus decreases the administration and development time of the whois database.

1 2

RE: [lir-wg] IPv6 assignments to RIPE itself
by matthew.ford＠bt.com 15 Jan '03

15 Jan '03

Hi, See below... -----Original Message----- From: Gert Doering [mailto:gert@space.net] Sent: Wed 15/01/2003 12:56 To: Ford,M,Mat,DEN5 FORDM5 R Cc: gall(a)switch.ch; gert(a)space.net; bortzmeyer(a)gitoyen.net; jeroen(a)unfix.org; woeber(a)cc.univie.ac.at; lir-wg(a)ripe.net Subject: Re: [lir-wg] IPv6 assignments to RIPE itself Hi, On Wed, Jan 15, 2003 at 11:25:12AM -0000, matthew.ford(a)bt.com wrote: > Allocate /48s, exhaust existing RIR allocation, get more addresses from RIR. > > I don't see the problem. The current way that the RIRs and IANA allocates space *is* a problem, because it leads to "multiple prefixes per LIR", which is bad bad bad bad. => which is why ripe-261 is being developed. Mat.

2 1

80.x.x.x cannot resolve .zw addresses
by Chris Ransley 15 Jan '03

15 Jan '03

Hi guys, We are having an issue when trying to resolve Zimbabwe address eg: cfs.co.zw, zol.co.zw. I tried on two 80.x.x.x networks. 80.71.96.0 255.255.240.0 & 80.77.192.0 255.255.240.0 Can anyone help? Best Regards, Christian Ransley B.Sc. Web & Technical Services Manager Keyworld Ltd. UB42, Industrial Zone San Gwann SGN 09 Tel: (+356) 2540 2540 Fax: (+356) 2540 9999 Email: webmaster(a)keyworld.net Website: http://www.keyworld.net

2 1

IPv6 assignments to RIPE itself
by Robert Kiessling 15 Jan '03

15 Jan '03

Hello, RIPE uses addresses which are unassigned: > host -t aaaa ns.ripe.net. ns.ripe.net IPv6 address 2001:610:240:0:193::193 > whois 2001:610:240:0:193::193 inet6num: 2001:0610:0240::/42 netname: RIPE-NCC-IPv6 descr: RIPE NCC status: ALLOCATED-BY-LIR In my understanding, this is not an allowed usage sice RIPE must assign a /48 to themselves before the use the address space. However, I rose this issue with them, and they claim there is not need for this. Could someone please explain to me where my understanding of the allocation and assignment rules is flawed? Thank you, Robert

5 10

RE: [lir-wg] IPv6 assignments to RIPE itself
by matthew.ford＠bt.com 15 Jan '03

15 Jan '03

> -----Original Message----- > From: Alexander Gall [mailto:gall@switch.ch] > Sent: 15 January 2003 09:15 > To: Gert Doering > Cc: Stephane Bortzmeyer; Jeroen Massar; 'Wilfried Woeber, > UniVie/ACOnet'; lir-wg(a)ripe.net > Subject: Re: [lir-wg] IPv6 assignments to RIPE itself > > > [Probably opening a can of worms here...] Yuk, worms taste bad .... ;-) <snip> > I agree. The numerics in section 4 of RFC3177 assume that the top 45 > bits in 2000::/3 can be utilized with an H ratio of 0.25 (giving on > the order of 10^11 /48). IMHO, the problem with the current > allocation policy is that it is a lot more conservative than RFC3177 > suggests while still holding on to the /48-for-everybody rule. The > relatively small LIR allocations create a level of scarcity in the > number of /48's, which is enough to make people believe that giving a > student as much address space as her entire University is just crazy. > However, the whole point of RFC3177 was that this should be completely > irrelevant. It *is* completely irrelevant. Allocate /48s, exhaust existing RIR allocation, get more addresses from RIR. I don't see the problem. -- Mat.

6 11

Re: [lir-wg] IPv6 assignments to RIPE itself
by Wilfried Woeber, UniVie/ACOnet 15 Jan '03

15 Jan '03

>> Alexander Gall has summarized it pretty well - if we want to give out >> /48s freely, then the quite conservative RIR->LIR allocation policy >> currently in place *hurts*. > >Very true if you mean that you cannot build a reasonable hierarchy. Actually, this is the thing that makes the use of the /42 block out of SURFnet's sTLA to RIPE (Meeting et.al.), The NCC and the employees interesting: I do see it as people actually trying to _live_ and document that hierarchy - LIR => RIPE NCC (status: ALLOCATED-BY-LIR) => various assignments by the RIPE NCC. >> As for the argument "are universities ISPs"? Yes, at least over here, >> a fair number of them are providing IP connectivity to the student's >> hostels via leased line/ethernet, and to all other students via ISDN/Modem >> dialup. So for all address management purposes, they are ISPs. > >This is true in the Netherlands too. Same here. We even operate our own ADSL gear on-site for connecting hostels, students, etc. >Yes, I think those should be treated >as ISPs, probably getting a prefix (>> /48) from their NRN. That's something we are trying to get a feeling for at the moment. My approach for _now_ is to treat a University's (extended) LAN as one site (i.e. lives within 1 /48), and the hostels and remote customers' (students and faculty) networks as a site (/48 typically or /64 in special circumstances) each. As regards the address distribution procedures I still maintain that there is no technical or logical difference between a university's "customer" which happens to be staff or student as compared to a "regular" customer serviced by a "commercial" ISP. Also, the technology used to ship IPv6 packets should be irrelevant for this discussion, i.e. a native link or an IPv6 in IPv4 tunnel to such a network doesn't make a difference. > rvdp Btw, regarding the discussion of what a "site" is - my current interpretation here is that a "site" is the entity I am talking to with regard to network planning and address space management. And if that entity most probably uses more than a singel subnet, then I usually stick to the /48 recommendation. Wilfried. _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

2 1

Re: [lir-wg] IPv6 assignments to RIPE itself
by Wilfried Woeber, UniVie/ACOnet 15 Jan '03

15 Jan '03

Sorry, Gert, >> As Leo already explained: RIPE != RIPE NCC. I see the usefulness of >> a /48 that travels along with the RIPE meetings. As far as I know, >> this /48 always has the same upstream (the RIPE _NCC_ office) by >> means of a v6-in-v4 tunnel. > >And exactly this is the reason why I don't see the need for a second /48. I don't get your point here. What are you trying to salvage? 1x /48 out of SURFnet's sTLA or 1x /48 out of the /42 or ?? Wilfried.

2 1

RE: [lir-wg] should aut-num object for IPv4 & IPv6 be the same?
by adrian.pauling＠bt.com 15 Jan '03

15 Jan '03

we have 'inet6num' objects separate to 'inetnum' to distinguish IPv6 address assignments from IPv4. Is the question should different 'peering-set' 'route' objects etc reflect different peerings for IPv6 from IPv4 that an assigned AS can have? This scenario is real as I can easily give a current (enterprise LIR) example. Regards, Adrian F Pauling BT Ignite Solutions

2 1

Re: [lir-wg] IPv6 assignments to RIPE itself
by Wilfried Woeber, UniVie/ACOnet 15 Jan '03

15 Jan '03

>| > whois 2001:610:240:0:193::193 >| inet6num: 2001:0610:0240::/42 >| netname: RIPE-NCC-IPv6 >| descr: RIPE NCC >| status: ALLOCATED-BY-LIR I think there are 2 questions here that should be discussed, under the premises that SURFnet has set aside a /42 for the NCC from SURFnet's sTLA: a) what is the "correct" status: field for a block bigger than /48 I think in most cases (like /47, /46 for a big site) it should simply be ASSIGNED, even if it is as big as a /42. b) in a more general sense, to what level are we (LIR) and our sites/customers (/64, /48 or bigger) expected to document internal address management? For the moment, the only thing that looks funny _for me_ is the status: "ALLOCATED-BY-LIR". I read that as an indication that the NCC would make _assignments_ from that block, e.g. /64s and /48s - which I think _should_ be registered by the NCC or by SURFnet. Wilfried.

7 8

should aut-num object for IPv4 & IPv6 be the same?
by Andrius Kasparavicius 15 Jan '03

15 Jan '03

hello, IPv6 AS policy can differ from IPv4, should we ignore IPv6 then? Andrius

2 1

RE: [lir-wg] IPv6 assignments to RIPE itself
by Wilfried Woeber, UniVie/ACOnet 15 Jan '03

15 Jan '03

Hi Jeroen! >Only problem here is that in the non rwhois databases there is no >defacto 'referal' method. At least as far as I know of except for >a 'remarks:' field. If somebody can hint me where to find it I would >be pleased. Interesting line of thought! In fact there _is_ a referral mechanism - for domain lookups, but not for address lookups. Depending on what the result of this discussion is, we could investigate the merits of a referral mechanism for inet6nums, too. Nevertheless I'd strongly suggest to keep the (minimal) required documentation of resources in the central database, instead of going down the route of rwhois (or the like). Wilfried.

2 1

Re: [lir-wg] IPv6 assignments to RIPE itself
by Andrei Robachevsky 14 Jan '03

14 Jan '03

Dear Robert, colleagues, > Hello, > > RIPE uses addresses which are unassigned: > > > host -t aaaa ns.ripe.net. > ns.ripe.net IPv6 address 2001:610:240:0:193::193 > > > whois 2001:610:240:0:193::193 > inet6num: 2001:0610:0240::/42 > netname: RIPE-NCC-IPv6 > descr: RIPE NCC > status: ALLOCATED-BY-LIR > > In my understanding, this is not an allowed usage sice RIPE must > assign a /48 to themselves before the use the address space. > This is our fault that the assignments we made were used before they were registered as inet6num objects with "ASSIGNED" status. This has now been corrected. I would like to note that this space wasn't allocated by the RIPE NCC to the RIPE NCC itself, but rather by SURFnet to their customer - RIPE NCC operations department and then assigned to their customers - RIPE NCC's network, RIPE meeting network and home networks of the NCC's staff. I must also apologise to SURFnet as this might have affected their HD ratio. > However, I rose this issue with them, and they claim there is not need > for this. > > Could someone please explain to me where my understanding of the > allocation and assignment rules is flawed? > > Thank you, > > Robert > Regards, Andrei Robachevsky CTO, RIPE NCC

1 0

RE: Re[2]: [lir-wg] Name of the LIR WG
by Wilfried Woeber, UniVie/ACOnet 14 Jan '03

14 Jan '03

Thanks, John, >My, I hope reasonably correct and not too long winded comments: I think this was a very well-structured summary. Just one additional clarification: >The NCC has members who pay membership fees and gain neutral services for >those fees. The services are defined/agreed by membership via activity >plans etc. Typically those members (the LIRs) are organisations (ISPs, companies, associations,...) and, depending on their size and thus financial contribution, can control a certain number of votes in the NCC's AGM (the Association's General Assembly). >Many NCC members, called "Local Internet Registries" are also participants in RIPE. >You "participate" in RIPE rather than being a "member" as it doesn't have a formal >organisational structure. However, even if a person happens to be affiliated with an LIR, the person participates in RIPE as an individual! In the sense of one person, one point of view to be considered for consensus development. Right? Wilfried.

1 0

Fwd: [lir-wg] Re: [lir-wg]Election of chairs to the lir-wg - call for nominations
by Kurt Erik Lindqvist 14 Jan '03

14 Jan '03

Ok, on the request of Hans Petter I resubmit this. Note that I have no idea if Gert is willing or not I just went for someone I think have shown good understanding and reason :) Best regards, - kurtis - Begin forwarded message: > From: Hans Petter Holen <hpholen(a)tiscali.no> > Date: tor jan 2, 2003 21:38:34 Europe/Stockholm > To: Kurt Erik Lindqvist <kurtis(a)kurtis.pp.se> > Subject: Re: [lir-wg] Re: [lir-wg]Election of chairs to the lir-wg - > call for nominations > > Thanks Kurtis, > Were supposed to be open and transparent :-) so could I ask you to > resent the message to the list ? > > -hph > > --On 2. januar 2003 12:21 +0100 Kurt Erik Lindqvist > <kurtis(a)kurtis.pp.se> wrote: > >>> I would think it should be fairly important to the wg to figure out: >>> >>> 1) Who should chair this wg in the future ? >> >> I am not sure if this is supposed to be open or closed so I mail this >> to >> only you. I would nominate yourself. >> >>> 2) Are the current chairs accepting renomination ? (yes I am if you >>> still want me :-) >> >> See above :) >> >>> 3) Does the wg want to have 1 chair and 2 co chairs ? >>> >> >> I suggest two co-chairs. Without discussing this with anyone, I would >> suggest Gert Doering as one, but I would also liek us to find someone >> from the enterprise side as the other. >> >> - kurtis - > > >

2 1

APNIC New IPv6 address block
by John Tran 14 Jan '03

14 Jan '03

Dear colleagues APNIC received the IPv6 address range 2001:0E00::/23 from IANA in January 2003 and will be making allocations from this range in the near future. Please configure your routing filters accordingly. For more information on the resources administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, see: http://www.apnic.net/db/min-alloc.html Kind regards Son ____________________________________________________________________ Resources Services Manager <Son(a)apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk(a)apnic.net Please send Internet Resource Requests to <hostmaster(a)apnic.net> _____________________________________________________________________ * APNIC-ANNOUNCE: Announcements concerning APNIC * * To unsubscribe, send "unsubscribe" to apnic-announce-request(a)apnic.net * * APNIC-TALK: General APNIC Discussion List * * To unsubscribe: send "unsubscribe" to apnic-talk-request(a)apnic.net *

1 0

Name of the LIR WG
by Denesh Bhabuta 10 Jan '03

10 Jan '03

Hi I am sure we all agree that this Working Group is an "open forum where RIPE policy is made". However this is not immediately obvious from the name Local Internet Registry Working Group (LIR WG). There seem to be a couple of apparent problems... 1) The Purpose of the working group is not clear - mainly to newcomers, but also to others. 2) non-LIRs most likely have the impression that the Working Group is not open to them even though it is open to anyone with rational argument. Thus a proposal is to change the name of this working group to "Policy WG" or similar.. if only to remove any implications of the WG being a closed shop. This would also make it clear as to what the WG deals with. So - any comments? Please start a discussion on this in time for the upcoming meeting in Amsterdam where we hope there will be a consensus on this matter. Regards Denesh

11 14

[aso-council] ICANN Quarterly Report to U.S. Department of Commerce (fwd)
by Hans Petter Holen 10 Jan '03

10 Jan '03

------------ Forwarded Message ------------ Date: 9. januar 2003 18:26 -0800 From: "M. Stuart Lynn" <lynn(a)icann.org> To: ASO Council <aso-council(a)aso.icann.org> Cc: vint cerf <vcerf(a)MCI.NET> Subject: [aso-council] ICANN Quarterly Report to U.S. Department of Commerce The amendment signed last September to the Memorandum of Understanding with the U.S. Department of Commerce requires ICANN to submit a quarterly progress report detailing our accomplishments towards fulfilling the requirements of that amendment. The report covering the period from the signing of the amendment through December 31, 2002 has been submitted and can be found at http://www.icann.org/general/status-report-08jan03.htm. The report highlights not just all that has been done towards achieving the reform of ICANN, but also the significant progress that has been made in many other important areas. I would like to thank each of you for all of your support and dedicated efforts towards both the reform efforts and some of these other areas of accomplishment. Without your voluntary commitment of your precious time, none of this would have been possible. With best wishes for 2003 and for continuing collaborations! Stuart -- __________________ Stuart Lynn President and CEO ICANN 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 Tel: 310-823-9358 Fax: 310-823-8649 Email: lynn(a)icann.org * on-line archive: http://aso.icann.org/wilma-bin/wilma/aso-council * * To unsubscribe: send "unsubscribe" to aso-council-request(a)aso.icann.org * ---------- End Forwarded Message ----------

1 0

Re: [lir-wg] Name of the LIR WG
by Hans Petter Holen 08 Jan '03

08 Jan '03

--On 8. januar 2003 17:40 +0100 Daniel Karrenberg <daniel.karrenberg(a)ripe.net> wrote: | | "Registration Policies and Procedures WG" repop-wg ? To add the global perspective: ARIN: IP Allocations Policies Working Group policy(a)arin.net APNIC: Address Policy SIG LACNIC: Politicas -- Lista de discucion de politicas del LACNIC The main works have been named: ripe-246 IPv6 Address Allocation and Assignment Policy ripe-245 Autonomous System (AS) Number Assignment Policies and Procedures ripe-244 Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region ripe-234 IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region ripe-127 Provider Independent vs Provider Aggregatable Address Space So so far we have not used the term Registration Policy. I also feel that the game is about how have an address assigned, not how to register the address of my preference. Maybe IP address Policies and Procedures WG: iapp-wg or simply address Policies and Procedures: app-wg But I somehow feel this is just making more cryptic abreviations not adding transparencey to the name. -hph

1 1

Re: [lir-wg] Name of the LIR WG
by Wilfried Woeber, UniVie/ACOnet 08 Jan '03

08 Jan '03

Hi Daniel, Gert et.al.! IF we really consider changing things, after a _very_ careful review (I hope), I'd have a strong pref to do it in coordination with the other RIRs' constituencies. >Hi, > >On Wed, Jan 08, 2003 at 05:40:56PM +0100, Daniel Karrenberg wrote: >> "Registration Policies and Procedures WG" repop-wg ? > >I'm not sure whether people will understand "repop-wg" better than >"lir-wg" :-) > >What about "policy-wg"? "policy" -- policy? what (Internet Content ;-) ?? The best thing I can think of at the moment is sort of copying from the APNIC region, ie. [IP] Address Policy SIG. Which (from an ICANN/ASO point of view) still misses the routing identifier issue, somewhat, and/or potentially starts to pull the Routing-WG into the boat as well. And we should be very careful to not _add_ to the confusion in this process, with - policy being the "open-ness" thingy where everyone is welcome and a consensus and/or resource accessibility and distribution decision should be worked out, and - defining the procedures, which should ultimately remain the responsibilty of the NCC and the LIRs in th end, although everyone should still be welcome to observe and contribute as much as possible. We should think pretty careful about - "policy development" for IPv[46] Addresses and Routing Identifiers, - "LIR <-> RIR procedure definitions" and, in the end, - "funding agreement". >Gert Doering > -- NetMaster Food for thought, Wilfried.

1 0

RE: [lir-wg] Name of the LIR WG
by paul.mylotte＠bt.com 08 Jan '03

08 Jan '03

I tend to favour the official title of "IP Addressing Policy" WG, which can then be abbreviated to the informal "Policy" WG if necessary Paul -----Original Message----- From: Peter Galbavy [mailto:peter.galbavy@knowtion.net] Sent: 08 January 2003 16:50 To: Gert Doering; Axel Pawlik; Denesh Bhabuta; lir-wg(a)ripe.net Subject: Re: [lir-wg] Name of the LIR WG > I'm not sure whether people will understand "repop-wg" better than > "lir-wg" :-) > > What about "policy-wg"? There appears to be a focus of 'RIPE is the members' so why not 'ripe-wg' ? Peter

1 0

New Draft Document
by RIPE NCC Document Announcement Service 08 Jan '03

08 Jan '03

New RIPE Draft Document Announcement -------------------------------------- A new draft document is available from the RIPE document store. Draft: IPv4 Sub-allocations Made by Local Internet Registries Operating within the RIPE NCC Service Region Short content description ------------------------- This document specifies the RIPE community policies on allocations made by Local Internet Registries (LIRs) within the unicast IPv4 address space. The draft document is available at: http://www.ripe.net/ripe/draft-documents/sub-allocations.html The deadline for comments on this draft document will be accepted up to and including 29 January 2003. 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>. Kind Regards, Jeroen Bet RIPE NCC Webmaster

1 0

Recent Board Meeting
by Axel Pawlik 07 Jan '03

07 Jan '03

Dear all, I want to take this opportunity to wish you a very Happy and Successful New Year! ... and to quickly inform you that the Executive Board of the RIPE NCC met on 16 December 2002. During the meeting a number of issues that were brought up on this mailing list some weeks ago were discussed. A major focal point was on easing members' participation in the annual General Meeting of the association. Various possibilities ranging from electronic voting to moving the date of the meeting were considered. Another topic was the presentation of budget lines in documents like the Annual Report and Activity Plan, as well as possible improvements to the current Charging Scheme. No final decisions have been taken yet, as a substantial amount of further discussions and preparations are expected. I will present more details, and give an outlook onto the RIPE NCC actions in the coming year, during the plenary at the upcoming RIPE Meeting. kind regards, hope to see you in Amsterdam, Axel

1 0

ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8
by Joe Baptista 03 Jan '03

03 Jan '03

ARIN recently released blocks from the 69.0.0.0/8 which are causing numerous problems with routing in this block. Some 200 blocks have been issued from 69.0.0.0/8 and i've spoken with at least 15 operators who have complained. I understand the 82.0.0.0/8 block suffers from the same problem. From what I can see RIPE has not yet issued any netblocks from this pool. If RIPE does issues blocks from this pool will RIPE take back the IP if it enconters the same problems or will RIPE follow the ARIN approach of no returns even though ARIN and RIPE are aware of the frustration it is causing. Some operators I have spoken with in 69/8 have suffered damage to thier business operations. Cheers Joe Baptista -- Planet Communications & Computing Facility a division of The dot.GOD Registry, Limited

8 9

RE: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0. 0.0/8
by Sweeting, John 02 Jan '03

02 Jan '03

None of the RIR's are going to tell me what routes I will accept or filter in my network.....as simple as that. If I am filtering out networks that my customers wish to get to then that will be fixed as soon as a ticet is opened by them. Also, what is with the "...you boys..." remarks. -----Original Message----- From: Joe Baptista To: leo vegoda Cc: lir-wg(a)ripe.net Sent: 1/2/03 7:18 AM Subject: Re: [lir-wg] ripe allocation 82.0.0.0/8 and arin allocation 69.0.0.0/8 On Thu, 2 Jan 2003, leo vegoda wrote: > The RIPE NCC can not guarantee whether any particular route will > be accepted by any network operator. Thats a problem. Question - if one of your customers discovers that an allocation does not route can they have it replaced with one that does. I understand you don't guarantee any particular allocation will route. And in the old days when the charges were minimal for IP allocation - well one could reluctantly accept that. However - under the new policies you boys are charging these people hefty bucks and that means liability and I don't think it prudent to hide behind the routing claim. I have documented over 15 cases in which the 69.0.0.0/8 fiasco has cost these people clients and business that went elsewhere. Have also documented situations in which these recent allocation have resulted in the renumbering of networks out of 69.0.0.0/8 allocations into arpa that works. So you see I think it prudent that there be a policy to allow for returns and replacement of arpa. I don't think you boys should be issuing numbers when you are aware that they don't work and are causing people financial problems to their business operations. So if you do get complaints regarding 82.0.0.0/8 - do you intend to make sure your customers get network that work - or will RIPE be following the ARIN lead and just let these people hang. regards joe baptista

1 0

Draft Agenda for RIPE 44 (version 0.3)
by Hans Petter Holen 01 Jan '03

01 Jan '03

Dear Working Group, Please find enclosed a draft agenda for the upcoming working group. As a matter of procedure I suggest that Policy items to be discussed are to be discussed at the mailinglist. We should aslo be careful not to make policy desicions at the upcoming meeting _unless_ there is a concrete proposal circulated to the list in advance of the meeting, we should circulate any policy proposals to this list after te meeting before making any policy desicions. Thanks to leo for preparing the very first draft, looking forward to input from the rest of you. Best Regards, Hans Petter Holen lir-wg chair --- Draft Agenda for RIPE 44 (version 0.2) Wednesday 29 January 2003 09:00 - 12:30 Chair: Hans Petter Holen Co-chair: Denesh Bhabuta A. Admin: Scribe Participant List, Charter, Mailing lists B. Agenda bashing C. RIPE 43 minutes and actions http://www.ripe.net/ripe/wg/lir/r43-minutes.html http://www.ripe.net/ripe/wg/lir/lir-actions.html D. Report from the RIPE NCC Registration Services Presentation by leo vegoda E. Report from the Address Council - Presentation F. Election of new LIR-WG Chairs G. LIR Portal H. Policy issues -- Mailing list AUP ? -- EGLOP Multicast policy discussion ? -- IPv6 policy - experiences ? -- IP addressing for always on (residential broadband) revisited ? X. Any other business Y. Summary of actions arising from this meeting Z. Open microphone

2 1