From iljitsch at muada.com Sat Sep 1 01:05:36 2007 From: iljitsch at muada.com (Iljitsch van Beijnum) Date: Sat, 1 Sep 2007 01:05:36 +0200 Subject: [address-policy-wg] Re: IPv6 addresses really are scarce after all In-Reply-To: References: <46C613E0.8010909@bogus.com> <46C629D2.20009@cs.utk.edu> <17CF54A9-299C-429F-9FCA-1BD57ADC795E@cisco.com> <46C6B5BB.5000203@cs.utk.edu> <200708242134.l7OLYa73026868@cichlid.raleigh.ibm.com> <70C6EFCDFC8AAD418EF7063CD132D064058BF1C2@WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com> <46D05897.5010906@cs.utk.edu> <59D5CFF02CEE1D3C96D66409@p3.JCK.COM> Message-ID: On 31-aug-2007, at 17:31, wrote: > I still have not seen > any clear indication that there is a negative technical impact of > assigning a /56 per home. Then you haven't been paying attention, I've been saying /56 is the wrong size for some time now. > To date, the only clear technical issue I have > seen mentioned for subnet prefixes longer than /48 is that if they are > not on a 4-bit hex nibble boundary, it makes IPv6 PTR delegation more > complex. Then you have to delegate 2, 4 or 8 zones rather than 1, big deal. From filiz at ripe.net Wed Sep 5 14:29:34 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 05 Sep 2007 14:29:34 +0200 Subject: [address-policy-wg] 2007-04 Proposal Accepted (IANA Policy for Allocation of ASN Blocks to RIRs) Message-ID: <20070905122934.2028E2F5A8@herring.ripe.net> PDP Number: 2007-04 IANA Policy for Allocation of ASN Blocks to RIRs Dear Colleagues Consensus has been reached, and the proposal described in 2007-04 has been accepted by the RIPE community. This proposal is to have a global policy for the Regional Internet Registries (RIRs) to receive blocks of Autonomous System Numbers (ASNs) from the Internet Assigned Numbers Authority (IANA). You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/2007-04.html Thank you for your input. Regards Filiz Yilmaz RIPE NCC Policy Development Officer From filiz at ripe.net Wed Sep 12 12:07:20 2007 From: filiz at ripe.net (Filiz Yilmaz) Date: Wed, 12 Sep 2007 12:07:20 +0200 Subject: [address-policy-wg] New Document available: ripe-416 Message-ID: <46E7BA58.3030605@ripe.net> Dear Colleagues, We previously announced that the policy proposal 2007-04, "IANA Policy for Allocation of ASN Blocks to RIRs" had been accepted by the RIPE community. This policy has now been published as a RIPE Document: ripe-416, "Internet Assigned Numbers Authority (IANA) Policy for Allocation of ASN Blocks to Regional Internet Registries" You can find this document at: http://www.ripe.net/ripe/docs/ripe-416.html Please note that this is a global policy and will therefore come into effect only after it has been accepted as a policy in all other RIR regions and then ratified by ICANN. Kind regards, Filiz Yilmaz RIPE NCC Policy Development Officer From jorgen at hovland.cx Thu Sep 13 10:15:18 2007 From: jorgen at hovland.cx (=?UTF-8?Q?J=C3=B8rgen_Hovland?=) Date: Thu, 13 Sep 2007 10:15:18 +0200 Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: In-Reply-To: <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> Message-ID: <04C313D8AB7246158A24E1BC7303AA7B@tungemaskin> I'm not sure if you have thought through your idea very thoughtfully, Mr Brown. The internet changes every second. It is more or less impossible to maintain proper information in ripe objects for end-users. An IP address can belong to customer A for 1 minute and then be taken over by customer B 5 seconds later in our net. If you want to contact the end-user directly, the RIPE whois server is not sufficient in the current state of today. Just keep contacting the ISP instead.. j -----Original Message----- From: address-policy-wg-admin at ripe.net [mailto:address-policy-wg-admin at ripe.net] On Behalf Of der Mouse Sent: 24. august 2007 20:55 To: apwg-chairs at ripe.net; address-policy-wg at ripe.net; anti-spam-wg at ripe.net Subject: [address-policy-wg] Re: [anti-spam-wg] Fwd: Re: Re: NCC#2007083003 Fwd: DELIVERY FAILURE: > I Matthew Brown, would like to request that there be some sort of > action, to allow the ripe database managers to contact ISP(s) when > someone reports incorrect or outdated information. Good luck - and I mean that; I hope you succeed, though at this point I don't really expect it. I've gone a few rounds with RIPE myself on that issue; they appear to want the authority of "owning" (and being paid for the subdelegation of) address space without the concomitant responsibility. Not surprising, of course; lots of people would rather pocket the money and duck the responsibility. The real problem is that ICANN/IANA lets them get away with it, and I see that (that the top of the governance pyramid does not impose responsibility on those to whom it delegates authority - and I don't mean just RIRs; the same problem recurs with domains) as the fundamental problem that is killing today's net with abusers and abuses. Any system with mismatches between authority and responsibility grows abuses, until one of three things happens: (1) the mismatch is corrected, (2) the system collapses, or (3) in mild cases, an equilibrium is reached, with the level of abuse concomitant with the level of mismatches. In the case of Internet governance, the mismatch appears to be total, so (3) is out, and there appears to be no will whatever to do (1), so I expect the abuses to simply grow until the net collapses from them. The only reason I'm not just standing back and watching it happen is that I'd like to have a usable Internet myself in the near term - during the time it would take for the current system to collapse and shake out something less broken. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML mouse at rodents.montreal.qc.ca / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B From jeroen at unfix.org Thu Sep 13 12:42:26 2007 From: jeroen at unfix.org (Jeroen Massar) Date: Thu, 13 Sep 2007 11:42:26 +0100 Subject: [address-policy-wg] Working Contact Information (Was: ..... NCC#2007083003 Fwd: DELIVERY FAILURE:) In-Reply-To: <04C313D8AB7246158A24E1BC7303AA7B@tungemaskin> References: <152533.59187.qm@web33106.mail.mud.yahoo.com> <200708241908.PAA02461@Sparkle.Rodents.Montreal.QC.CA> <04C313D8AB7246158A24E1BC7303AA7B@tungemaskin> Message-ID: <46E91412.2030502@spaghetti.zurich.ibm.com> [re-ordering message flow so it makes sense again + reformat to 80c] > Matthew Brown wrote: >> I Matthew Brown, would like to request that there be some sort of >> action, to allow the ripe database managers to contact ISP(s) when >> someone reports incorrect or outdated information. J?rgen Hovland wrote: > I'm not sure if you have thought through your idea very thoughtfully, > Mr Brown. The internet changes every second. It is more or less > impossible to maintain proper information in ripe objects for > end-users. An IP address can belong to customer A for 1 minute > and then be taken over by customer B 5 seconds later in our net. > If you want to contact the end-user directly, the RIPE whois server > is not sufficient in the current state of today. > Just keep contacting the ISP instead.. He actually mentioned contacting the ISP, not the end-user. They are the ones responsible and they are also the ones that can act on problems. The only way the end-user would be responsible is when they are in effect the ISP. BOTH inet[6]nums and domain.tld (different story I know) should have a contactable address for technical and especially abuse issues. This contact address should simply be the ISP NOC. Indeed, I note that domain.tld should have two types of information: 'registrant', specifying who 'owns' the record. For all those whois privacy freaks you can omit that, most likely the person who registered it can't fix problems with it any way, but the Admin contact Tech can, and that one should never be hidden. Same for inet[6]nums, Tech contact should always be contactable, the inet[6]num might/should contain a short description of who it is assigned to, but most of the time it should not matter. They a hint of 'dynamic home user space' or something is appreciated by most people who actually look up whois info to try and resolve issues. Again, the tech-c should always be contactable, as that is the one who is responsible for fixing problems. This problem might be for instance that you notice that that prefix is unreachable or has other issues and just that you want to help them out. And IMHO a tech-c should always point to a role account, not to a single person. The Internet is a 24/7 hour business and nobody is awake 24/7 ;) By contact I mean three items: email + phone + street address I note 'street address' as there is bound to be an office where this ISP is located, POBOX's are just for hiding obscure companies. One should not have nothing to hide. Note that a role can be updated really easily and in one place, similar to a organization object. I would suggest that there is like an easy way to trigger a process at RIPE NCC when one could not contact a certain ISP by the means given, phone being the most important one (note that it can be a VoIP one, those have DIDs too). To limit overload of these requests, one could require that the requester is an ISP itself (eg has an inet6num/tech-c combo). Marking the data invalid can can be done when for instance the phone still doesn't get picked up after X days one is really not running a proper ISP business and certainly not taking responsibility for the networks that one should be responsible for. The sad part of course is that even when the data is marked invalid, there is no way to actually come in contact with the ISP and/or getting the ISP to fix the problems. Even a global BGP certificate setup won't help, unless the larger transits and in effect the majority will adhere to that and also allow RIRs toe revoke those certificates based on this. As ISPs and especially also enterprises will never allow a small group to have so much control over them, that will never ever happen :( Actually what this really all comes down to is inter-ISP problem reporting, which, like the above would definitely require agreement between ISPs and also good communication. The problem there of course is that the ISPs who act responsibly will cooperate in this, the ones that are not, will not. Not even forgetting of course about the nasty fact that it requires global Greets, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 311 bytes Desc: OpenPGP digital signature URL: From alexlh at ripe.net Tue Sep 18 11:06:09 2007 From: alexlh at ripe.net (Alex Le Heux) Date: Tue, 18 Sep 2007 11:06:09 +0200 Subject: [address-policy-wg] New AS Number Block allocated to the RIPE NCC Message-ID: <84522678-40DE-4E78-BCF5-AB2DD6C40A3B@ripe.net> Dear Colleagues, The RIPE NCC received the AS Number Block 44032 - 45055 from the IANA in September 2007. You may want to update your records accordingly. Best regards, Alex Le Heux RIPE NCC From nominations at ripe.net Wed Sep 19 14:12:18 2007 From: nominations at ripe.net (Paul Rendek) Date: Wed, 19 Sep 2007 14:12:18 +0200 Subject: [address-policy-wg] ASO AC: RIPE NCC Call for Nominations for ASO AC Seat Message-ID: <46F11222.5060209@ripe.net> [Apologies for duplicate e-mails] Dear Colleagues, This is a call for the RIPE community to nominate individuals from the RIPE NCC service region to serve on the Address Supporting Organization (ASO) Address Council (AC). Hans Petter Holen (Visma IT AS) vacates his seat on 31 December, ending his three-year term. Important ---------- The ASO Memorandum of Understanding (MoU) states that the public nomination period should open 90 days in advance of the next open policy meeting (RIPE 55) and close 30 days before the start of this meeting. Due to an oversight in the RIPE NCC's administrative procedure, this public nomination period was not announced to the RIPE community at the scheduled time. We apologise for any inconvenience this may have caused. If there are no objections from the community, we would like to proceed with the nomination process as follows: - 19 September: Nomination period opens - 15 October: Nomination period closes - 15 October: Complete Nomination list posted at: www.ripe.net/info/resource-admin/aso2007/nominations.html - 25 October: Elections take place during the RIPE Address Policy Working Group session at RIPE 55 How to Nominate Candidates ----------------------- Please send your nominations to nominations at ripe.net by 23:00 UTC on 15 October 2007. For details of the information that must be included with your nomination please see: www.ripe.net/info/resource-admin/aso2007/index.html More Information ---------------- Information about the ASO AC and the nomination procedure can be found at: http://aso.icann.org/ac/ Information about the election procedure during RIPE 55 can be found at: www.ripe.net/info/resource-admin/aso2007/selection-procedure.html More information about RIPE 55 can be found at: http://www.ripe.net/ripe/meetings/ripe-55/index.html Kind regards, Paul Rendek Head of External Relations & Communications RIPE NCC