This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Transfer Requirements for IPv4 Allocations
- Previous message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
- Next message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Opteamax GmbH
ripe at opteamax.de
Thu Apr 23 16:35:46 CEST 2015
On 23.04.2015 16:13, Vladimir Andreev wrote: > OK. I explain this one more time :) > > Just after receiving /22 you should create 2 x "inetnum" (each /23) with type ASSIGNED PA. Formally you are right since you have made assignments. Which is not the intention. but I agree, obviously we need to clarify what an assignment is. Please refer to chapter 6 of ripe-643. ASSIGNED PA: This address space has been assigned to an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. So "making an assignment" does *not* mean create a /23 inetnum in RIPE-DB. If this is your understanding of what an LIR does ... no further comment. BR Jens > > Furthermore you can create "route" object and announce your /22. In such case nobody can say "you don't use you allocation" or "you didn't make assignments". > > 23.04.2015, 17:08, "Jens Ott - Opteamax GmbH" <jo at opteamax.de>: >> On 23.04.2015 14:45, Vladimir Andreev wrote: >>>> The LIR must confirm it will make assignment(s) from the >>>> allocation. >>> Please point me where in quoted text you see any prohibition to >>> open and merge LIRs with /22's? >> >> Buying and merging is not prohibited, _but_ opening LIR, requesting >> /22 and selling /22 and closing LIR ist probibited, as the LIR did not >> fullfil his confirmed will to make assignments!! >> >> BR >> Jens >>> 23.04.2015, 15:43, "Gert Doering" <gert at space.net>: >>>> Hi, >>>> >>>> On Thu, Apr 23, 2015 at 03:41:10PM +0300, Vladimir Andreev >>>> wrote: >>>>> And why receiving /22's for own company is "legitimate" and for >>>>> selling is not? >>>> *one* /22 per LIR is the last-/8 policy >>>> >>>> not "open lots of LIRs, so a single LIR can have multiple /22s in >>>> the end, and circumvent the one-LIR-one-/22-allocated policy". >>>> >>>> Gert Doering -- APWG chair -- have you enabled IPv6 on something >>>> today...? >>>> >>>> SpaceNet AG Vorstand: Sebastian v. >>>> Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. >>>> Grundner-Culemann D-80807 Muenchen HRB: 136055 >>>> (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: >>>> DE813185279 >>> -- With best regards, Vladimir Andreev General director, QuickSoft >>> LLC Tel: +7 903 1750503 >>> >>> >> >> - -- >> Jens Ott >> - - Gesch?ftsf?hrer - >> >> Opteamax GmbH >> >> Simrockstr. 4b >> 53619 Rheinbreitbach >> >> Tel.: +49 2224 969500 >> Fax: +49 2224 97691059 >> Email: jo at opteamax.de >> >> HRB: 23144, Amtsgericht Montabaur >> Gesch?ftsf?hrer: Jens Ott >> Umsatzsteuer-ID.: DE264133989 >>> -----BEGIN PGP SIGNATURE----- >>> Version: GnuPG v2 >>> >>> iQEcBAEBCAAGBQJVOOrXAAoJECrmRJLVnvx6HRcIAK+EIe7EU2OCDjNC1f5v1JKd >>> xEIBbGiQN7k1TeQI2lPbW1WLZHGxHrFp9PCTHnT+T9uihIdnaj+O9Zv/Bq6MCy9r >>> qNopxk5DYOaljxcsiPuDHDNj1jvxbOmkSVSbaoZJ5VFlm4qLhZSOjvMJnYGvzBR8 >>> e/qX00EQAncyXSU4Iq59D9BK43iyYqvY/8Bvr1f7PSbNluEHM4zl6jHUoJR0WtDd >>> 8hlpWpjxz+tWtW9XhZm6EzzCwlnwrhdfTUr6sTA+f9pXJF2ypLf8SMJavi+Of2zi >>> MXzCrgO+GJzvIkcqxfjpzyQuoDNesN8fI9KrLk0Q1PYTv7MXZQquwVLbwx+79zc= >>> =LVL7 >>> -----END PGP SIGNATURE----- > > -- > With best regards, Vladimir Andreev > General director, QuickSoft LLC > Tel: +7 903 1750503 > > > !DSPAM:637,553900f431041558355978! > -- Opteamax GmbH - RIPE-Team Jens Ott Opteamax GmbH Simrockstr. 4b 53619 Rheinbreitbach Tel.: +49 2224 969500 Fax: +49 2224 97691059 Email: jo at opteamax.de HRB: 23144, Amtsgericht Montabaur Umsatzsteuer-ID.: DE264133989
- Previous message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
- Next message (by thread): [address-policy-wg] Transfer Requirements for IPv4 Allocations
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]