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] 2012-02 Discussion Period extended until 22 October 2012 (Policy for Inter-RIR Transfers of IPv4 Address Space)
- Previous message (by thread): [address-policy-wg] 2012-02 Discussion Period extended until 22 October 2012 (Policy for Inter-RIR Transfers of IPv4 Address Space)
- Next message (by thread): [address-policy-wg] 2012-02 Discussion Period extended until 22 October 2012 (Policy for Inter-RIR Transfers of IPv4 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore.anderson at redpill-linpro.com
Tue Sep 25 07:25:50 CEST 2012
* Emilio Madaio > The Discussion Period for the proposal 2012-02,"Policy for Inter-RIR > Transfers of IPv4 Address Space", has been extended until 22 October > 2012. I support this proposal, but wonder why it specifically refers to LIRs rather than something generic like «organisations»? That excludes transfers of direct assignments to/from End Users [who are not also LIRs]. In other places, the text refers to «any IPv4 address space», which seems to indicate that direct assignments are in scope, too. While it is the case that the RIPE region currently does not have a transfer policy for assignments, that may change in the future. I don't know about other regions (but obviously policies may change here too). Some hypothetical examples (I am assuming we are not running into any restrictions found in the remote region's transfer policy): 1) A RIPE region LIR wants to transfer and unused IPv4 allocation to an out-of-region End User (who is not a LIR), which will register the prefix in the Destination RIR's database as a direct assignment. 2) Same as #1, but the End User happens to also be a LIR. 3) An out-of-region End User (who is not a LIR), has a unused IPv4 direct assignment he wishes to transfer to a RIPE region LIR, who intend to register the prefix in the RIPE database as ALLOCATED PA. 4) Same as #3, only that the End User happens to also be a LIR. As I understand the proposed policy, #1 and #3 would not be allowed, but #2 and #4 would. Is my understanding correct? Also, assuming that a transfer policy has since been established in the RIPE region covering transfers of direct assignments: 5) Out-of-region End User wants to transfer a direct assignment to a RIPE region End User. Neither are LIRs. This would not be permitted by this policy either, correct? Finally, an editorial/language feedback: «Apart from transfers of address space within the service region of the RIPE NCC, this policy defines the framework that outlines what specific rules apply to IPv4 address space transfers in between the different RIR regions.» Native speakers please correct me if I'm wrong, but I've been taught that if you say «Apart from This, That» in English, the logical interpretation of that statement is "This AND That" (with an emphasis on "That"). It is however fairly clear from reading the rest of the proposal that the intended logical meaning in this case is "not(This) AND That". I don't think it particularly good form to start a policy with a statement of what it *isn't*, so I would suggest simply deleting the entire «Apart from transfers of address space within the service region of the RIPE NCC,» text. It is redundant in any case, as section 1.1 clearly declares in-region transfers as being out of scope. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/
- Previous message (by thread): [address-policy-wg] 2012-02 Discussion Period extended until 22 October 2012 (Policy for Inter-RIR Transfers of IPv4 Address Space)
- Next message (by thread): [address-policy-wg] 2012-02 Discussion Period extended until 22 October 2012 (Policy for Inter-RIR Transfers of IPv4 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]