Re: Creation of Reverse Delegation Objects
Hi Dominic,
Date: Wed, 24 Apr 2002 17:00:28 +0200 To: Tanja Heimes <theimes@de.cw.net> From: Dominic Spratley <dominic@ripe.net> Subject: Re: Creation of Reverse Delegation Objects CC: lir-wg@ripe.net
Hi Tanja,
There are several reasons why we do not accept requests directly from end-users. Most are based on the fact that the Internet Registry system is hierarchical. This means that we are funded by LIRs to provide services to them, not to end-users.
From _quite_ a distance, I tend to agree, in principle, but. Looking at the details, you are (from my point of view) over-simplifying the situation. E.g. there are probably quite a few holders of "traditional" address space which have a considerably higher clue-level that some LIRs. And, there _IS_ (or is this was?) a mandate for the NCC to provide services or functions for the community at large (just have a look at the annual activity descriptions which get agreed in the RIPE Community and ultimately get approved by the members once a year). Not all of these activities have to be channeled through (the wait queue for) a particular LIR. But my biggest point of concern here is that this is another instance where pretty *fundamental* operational (and policy) changes get implemented unilaterally by the NCC (should I say hostmaster group here?), without discussion, approval, and a look at the consequences and *NOT EVEN* an information being distributed those *AFFECTED*: the LIR community. We are left to find out by chance.
LIRs have more expertise in dealing with the RIPE Database than End Users. This is the main reason for requiring requests to come from them.
Yours sincerely,
Dominic Spratley,
R.S. Assistant Manager, RIPE NCC
In my books this is very bad management style! Respectfully, Wilfried Woeber, (at.aconet) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dear Wilfried, I wholeheartedly agree with your arguments: There *IS* indeed a mandate on the RIPE NCC to provide services to the community at large. The RIPE Database is a fine example. However, the handling of the in-addr tree is a membership service and as such only available to members of the RIPE NCC Association. I agree with the fact that old hats usually have greater knowledge than new hats (though not always). Those are usually either LIRs or have their address space registered at the ARIN Database (and yes this becomes an issue to discuss in view of the pending transfer of "legacy" space from ARIN to the RIPE NCC). I agree with the fact that the RIPE NCC should not change things unilaterally and without discussion (though we should not become inoperative). However Tanja is the one requesting the change. The RIPE NCC hasn't changed the behaviour of the in-addr robot for longer than I have been here (and that's about 50% of the RIPE NCC's life already) I agree that you don't want things like this to be put into a wait queue. The in-addr robot has nothing to do with any wait queue. If the command is sent correctly no hostmaster ever looks at the request. The robot analyzes it, does the DNS checks and registers the new set of name servers in the RIPE Database (assuming all is OK). Most of the requests get done that way, without human intervention. Having the reg.id enables the robot to check whether the requester is a member or not. I also agree that Dominic's mail might have been a bit oversimplified, probably from the fact that a lot of context was taken for granted. I hope to have filled you in with this message Regards, joao
There *IS* indeed a mandate on the RIPE NCC to provide services to the community at large. The RIPE Database is a fine example. However, the handling of the in-addr tree is a membership service and as such only available to members of the RIPE NCC Association.
I think Wilfrieds said:
But my biggest point of concern here is that this is another instance where pretty *fundamental* operational (and policy) changes get implemented unilaterally by the NCC (should I say hostmaster group here?), without discussion, approval, and a look at the consequences and *NOT EVEN* an information being distributed those *AFFECTED*: the LIR community. We are left to find out by chance.
I would rephrase: When was this deceided and by whom ? -hph
Dominic, I am sorry but if LIRs are more expertised in using the RIPE DB than end-users should not receive PI space, aut-num, and maintainer. Owners of PI space can update ther AS and PI inetnums and maintainer in the DB with their authorization method - so why should they not be able to update their reverse delegations of their PI space? If RIPE is serving only the RIPE community - than Provider Independent space should not exist. Regard, Tanja Heimes "Wilfried Woeber, UniVie/ACOnet" wrote:
Hi Dominic,
Date: Wed, 24 Apr 2002 17:00:28 +0200 To: Tanja Heimes <theimes@de.cw.net> From: Dominic Spratley <dominic@ripe.net> Subject: Re: Creation of Reverse Delegation Objects CC: lir-wg@ripe.net
Hi Tanja,
There are several reasons why we do not accept requests directly from end-users. Most are based on the fact that the Internet Registry system is hierarchical. This means that we are funded by LIRs to provide services to them, not to end-users.
From _quite_ a distance, I tend to agree, in principle, but.
Looking at the details, you are (from my point of view) over-simplifying the situation. E.g. there are probably quite a few holders of "traditional" address space which have a considerably higher clue-level that some LIRs.
And, there _IS_ (or is this was?) a mandate for the NCC to provide services or functions for the community at large (just have a look at the annual activity descriptions which get agreed in the RIPE Community and ultimately get approved by the members once a year).
Not all of these activities have to be channeled through (the wait queue for) a particular LIR.
But my biggest point of concern here is that this is another instance where pretty *fundamental* operational (and policy) changes get implemented unilaterally by the NCC (should I say hostmaster group here?), without discussion, approval, and a look at the consequences and *NOT EVEN* an information being distributed those *AFFECTED*: the LIR community. We are left to find out by chance.
LIRs have more expertise in dealing with the RIPE Database than End Users. This is the main reason for requiring requests to come from them.
Yours sincerely,
Dominic Spratley,
R.S. Assistant Manager, RIPE NCC
In my books this is very bad management style!
Respectfully, Wilfried Woeber, (at.aconet) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Dominic, I agree completely with Tanja. PI space should not be assigned to End-Users if they cannot be responsible for it, including the reverse delegation. Regards, Tanya Hinman -----Original Message----- From: owner-lir-wg@ripe.net [mailto:owner-lir-wg@ripe.net]On Behalf Of Tanja Heimes Sent: Wednesday, April 24, 2002 1:52 PM To: Wilfried Woeber, UniVie/ACOnet Cc: lir-wg@ripe.net Subject: Re: Creation of Reverse Delegation Objects Dominic, I am sorry but if LIRs are more expertised in using the RIPE DB than end-users should not receive PI space, aut-num, and maintainer. Owners of PI space can update ther AS and PI inetnums and maintainer in the DB with their authorization method - so why should they not be able to update their reverse delegations of their PI space? If RIPE is serving only the RIPE community - than Provider Independent space should not exist. Regard, Tanja Heimes "Wilfried Woeber, UniVie/ACOnet" wrote:
Hi Dominic,
Date: Wed, 24 Apr 2002 17:00:28 +0200 To: Tanja Heimes <theimes@de.cw.net> From: Dominic Spratley <dominic@ripe.net> Subject: Re: Creation of Reverse Delegation Objects CC: lir-wg@ripe.net
Hi Tanja,
There are several reasons why we do not accept requests directly from end-users. Most are based on the fact that the Internet Registry system is hierarchical. This means that we are funded by LIRs to provide services to them, not to end-users.
From _quite_ a distance, I tend to agree, in principle, but.
Looking at the details, you are (from my point of view) over-simplifying the situation. E.g. there are probably quite a few holders of "traditional" address space which have a considerably higher clue-level that some LIRs.
And, there _IS_ (or is this was?) a mandate for the NCC to provide services or functions for the community at large (just have a look at the annual activity descriptions which get agreed in the RIPE Community and ultimately get approved by the members once a year).
Not all of these activities have to be channeled through (the wait queue for) a particular LIR.
But my biggest point of concern here is that this is another instance where pretty *fundamental* operational (and policy) changes get implemented unilaterally by the NCC (should I say hostmaster group here?), without discussion, approval, and a look at the consequences and *NOT EVEN* an information being distributed those *AFFECTED*: the LIR community. We are left to find out by chance.
LIRs have more expertise in dealing with the RIPE Database than End Users. This is the main reason for requiring requests to come from them.
Yours sincerely,
Dominic Spratley,
R.S. Assistant Manager, RIPE NCC
In my books this is very bad management style!
Respectfully, Wilfried Woeber, (at.aconet) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber@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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Hi, On Wed, Apr 24, 2002 at 02:51:02PM -0400, Tanya Hinman wrote:
I agree completely with Tanja. PI space should not be assigned to End-Users if they cannot be responsible for it, including the reverse delegation.
I feel tempted to shorten that sentence further to "PI space should not be assigned to End-Users" but I am afraid this isn't too workable. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543 SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
Gert Doering wrote:
Hi,
On Wed, Apr 24, 2002 at 02:51:02PM -0400, Tanya Hinman wrote:
I agree completely with Tanja. PI space should not be assigned to End-Users if they cannot be responsible for it, including the reverse delegation.
I feel tempted to shorten that sentence further to
"PI space should not be assigned to End-Users"
.....this would propably solve the routability problems Tanja Heimes
but I am afraid this isn't too workable.
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 44543
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
participants (6)
-
Gert Doering -
Hans Petter Holen -
Joao Luis Silva Damas -
Tanja Heimes -
Tanya Hinman -
Wilfried Woeber, UniVie/ACOnet