Draft: "status:" re-evaluation
All, We recently proposed changes to the "status:" attribute values in the RIPE Database: http://www.ripe.net/ripe/draft-documents/status-attributes.html We have received input from APNIC on the subject. They proposed a simpler layout, and we think their suggestion makes sense. However, we would like to go forward with a slightly modified version that incorporates the "organisation" object we are working on. In the meantime, we do not want to delay the implementation of the Sub-Allocation policy. For that reason we'd like to have an interim status attribute value for that. Proposal: Add "SUB-ALLOCATED PA" to the allowed "status:" values. "SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an "LIR-PARTITIONED PA" less specific inetnum object. A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice. -- Shane Kerr RIPE NCC
Hi, On Wed, Aug 13, 2003 at 03:08:57PM +0200, Shane Kerr wrote:
In the meantime, we do not want to delay the implementation of the Sub-Allocation policy. For that reason we'd like to have an interim status attribute value for that.
I like that.
Proposal:
Add "SUB-ALLOCATED PA" to the allowed "status:" values.
That would be in agreement with the original proposal, so "I like that" (obviously).
"SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an "LIR-PARTITIONED PA" less specific inetnum object.
A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice.
I wouldn't force that on anyone. It might not always make sense, but we have at least one reseller that has a re-selling customer - so a two-level structure is already in place. So "please don't do that". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi *, * Gert Doering <gert@space.net> wrote:
I like that.
Me too.
A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice.
I wouldn't force that on anyone. It might not always make sense, but we have at least one reseller that has a re-selling customer - so a two-level structure is already in place.
So "please don't do that".
I disagree. Your customer should request a seperate "SUB-ALLOCATED PA" block for his customer or otherwise if he want's to look like being independent to his customer, he should become RIPE member. I hardly can't see advantages of making sub-sub-allocations (maybe you could point them out?). regards, sebastian -- whois: sabt-ripe - phone: +49 (0)174 3420738 email: sabt@sabt.net - pgp-pubkey: 0x3B046B48
Hi, On Wed, Aug 13, 2003 at 04:12:36PM +0200, Sebastian Abt wrote:
A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice.
I wouldn't force that on anyone. It might not always make sense, but we have at least one reseller that has a re-selling customer - so a two-level structure is already in place.
So "please don't do that".
I disagree. Your customer should request a seperate "SUB-ALLOCATED PA" block for his customer or otherwise if he want's to look like being independent to his customer, he should become RIPE member. I hardly can't see advantages of making sub-sub-allocations (maybe you could point them out?).
It's their suballocation, and their customer, not mine - how can I judge how big *their* customer is going to be, and how much address space they want? The whole point of suballocation is "give control to the people that actually hand out the addresses" - flexibility, instead of buerocracy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 56535 (56318) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Hi, * Gert Doering <gert@space.net> wrote:
It's their suballocation, and their customer, not mine - how can I judge how big *their* customer is going to be, and how much address space they want?
You won't judge. You give your customer's customer the allocation he needs (and the one that fits into your assignment window - or "sub- allocation window") as well as you give your customer the allocation he needs.
The whole point of suballocation is "give control to the people that actually hand out the addresses" - flexibility, instead of buerocracy.
Of course, and indeed, that's a "nice to have", but who controls the customer's customer assignments? In the end you're responsible for everything they do, because you are the one RIPE is going to contact in case of any trouble (at least that's what I'm reading in the draft). Erm, and what an assignment window do they have (or "sub-allocation window")? That are the questions confusing me. regards, sebastian -- whois: sabt-ripe - phone: +49 (0)174 3420738 email: sabt@sabt.net - pgp-pubkey: 0x3B046B48
I disagree. Your customer should request a seperate "SUB-ALLOCATED PA" block for his customer or otherwise if he want's to look like being independent to his customer, he should become RIPE member. I hardly can't see advantages of making sub-sub-allocations (maybe you could point them out?).
Oh i wish i had access to my old mail that i sent to this list. There is an argument for this but i fits the multi-national internet registry (MIR) structure much better. It is not necessarily for your customer but more a way of trying to control your internal routing tables. Does anyone have a copy of the MIR proposal they could repost. Which may help explain. Regards Stephen Burley Internet Communications consultant Africonnect
Stephen, Stephen Burley wrote:
Oh i wish i had access to my old mail that i sent to this list. There is an argument for this but i fits the multi-national internet registry (MIR) structure much better. It is not necessarily for your customer but more a way of trying to control your internal routing tables. Does anyone have a copy of the MIR proposal they could repost. Which may help explain.
I guess the RIPE mailing list archive could be of some help: http://www.ripe.net/cgi-bin/search/gdquery.cgi?header=ncc-head&footer=ncc-foot&terms=&record-type=paragraph&submit=Search&boolean=and&index=www-ripe-mail&show-context=1&max-results=100&page-results=10 And with the search terms "Stephen Burley MIR": http://www.ripe.net/cgi-bin/search/gdquery.cgi?index=www-ripe-mail&boolean=and&max-results=100&page-results=10&start-page=&header=ripe-mail-head&footer=ripe-mail-foot&record-type=paragraph&terms=Stephen+Burley+MIR&Search=Search&show-context=1°ree-of-error=0&sort=balanced&.cgifields=show-context&.cgifields=case-sensitive&.cgifields=search-substrings Sorry for the lengthy URLs - I directly copied them from my browser. Should work, though. Regards, Carsten Schiefner
Gert Doering, Gert Doering wrote:
Hi,
On Wed, Aug 13, 2003 at 03:08:57PM +0200, Shane Kerr wrote:
In the meantime, we do not want to delay the implementation of the Sub-Allocation policy. For that reason we'd like to have an interim status attribute value for that.
I like that.
Proposal:
Add "SUB-ALLOCATED PA" to the allowed "status:" values.
That would be in agreement with the original proposal, so "I like that" (obviously).
"SUB-ALLOCATED PA" inetnum object may have an "ALLOCATED PA" or an "LIR-PARTITIONED PA" less specific inetnum object.
A range of IP's can only have a single "SUB-ALLOCATED PA" in it. That is, you cannot sub-allocate twice.
I wouldn't force that on anyone. It might not always make sense, but we have at least one reseller that has a re-selling customer - so a two-level structure is already in place.
So "please don't do that".
Okay, this makes sense. This restriction will not be added. -- Shane Kerr RIPE NCC
Shane, On Wed, Aug 13, 2003 at 03:08:57PM +0200, Shane Kerr wrote:
We have received input from APNIC on the subject. They proposed a simpler layout, and we think their suggestion makes sense. However, we would like to go forward with a slightly modified version that incorporates the "organisation" object we are working on.
If you like their proposal, is there any reason why we cannot go ahead with their prososal instead of making yet another incompatible change between RIPE NCC and APNIC ?!? David K. ---
David Kessens wrote:
On Wed, Aug 13, 2003 at 03:08:57PM +0200, Shane Kerr wrote:
We have received input from APNIC on the subject. They proposed a simpler layout, and we think their suggestion makes sense. However, we would like to go forward with a slightly modified version that incorporates the "organisation" object we are working on.
If you like their proposal, is there any reason why we cannot go ahead with their prososal instead of making yet another incompatible change between RIPE NCC and APNIC ?!?
Aligning the policies and technologies as much as possible between the RIPE NCC and APNIC is indeed one of our goals. We have not rejected APNIC's input, but are rather working with them to refine the thinking on "status:" in both regions. We don't want to change the Database more than required, to avoid confusion and extra work for the users. Therefore we want the best solution to be the one we actually implement, hopefully in as many regions as possible. But it seems like this will take time, and we want to allow LIRs to sub-allocate as soon as possible. -- Shane Kerr RIPE NCC
participants (6)
-
Carsten Schiefner -
David Kessens -
Gert Doering -
Sebastian Abt -
Shane Kerr -
Stephen Burley