Destruction of trust
Hi, as you may be aware, the RIPE NCC is currently engaged in an activity to establish contact with legacy address space holders, and among other things to set up a contractual relationship between the RIPE NCC and the legacy resource holders. However, it is my opinion that the current RIPE NCC actions with legacy resource holders is destroying some of the valuable trust they have built in the community over the years. It has been said that "the RIPE NCC does what the members tell them to do". That does however not appear to be the case for this action, where the RIPE NCC appears to act in a policy-free zone, simply on executive decision. Despite the RIPE NCCs knowledge that work is ongoing to formulate a policy for this area, they are barging ahead, possibly in an attempt to establish a fait accompli. The message sent to the legacy resource holders does not mention the option which would probably be most preferable to at least most of our customers, namely registering the resources via the LIR at their service provider. One could suspect the RIPE NCC has self-interest in driving up the number of LIRs, to increase the number of paying customers of the RIPE NCC. Some of the documents about the approach with legacy resource holders has mentioned a "stick and carrot" approach. I'll claim that the stick is needlessly sharp and the carrot reeks of decomposition. Explanation: * The stick is primarily the "we cannot guarantee in-addr.arpa name service". Without it, a user will in practice be unable to operate mail servers within the affected address space, which would be a severe blow to those who still actively use their address space. The freezing of the registry data is an inconvenience which will ensure that the accuracy of the data whittles over time, an action initiated by the RIPE NCC no less... Many legacy resource holders have not updated their records in a long time already (many didn't have an actual need to do so), so while inconvenient, it's not as strong a stick as the threat of removal of the in-addr.arpa delegation. It should however be noted that the whittling of the registration data over time also is detrimental for the RIPE community at large, not only for the address space holder. * What's the carrot? Only the removal of the stick from above? What makes the carrot particularly rotten is several things: * The open-ended and unliateral application of "all relevant RIPE NCC policies and procedures". The fear would be "we will mire you or your LIR (or both) down in pointless address policy work to document ancient history, and have the RIPE NCC verify (or deny, as the case may be) all assignments done over time" (applicable where address space has been used in PA-fashion). ...or for PI-style assignments, the assignment itself might be challenged. * The highly uncertain status of the charging scheme in the longer term for the legacy resource holders, where the initial proposal to modify today's model had, with no discussion, abolished the "age based discount", and where current discussion is rampant with "payment per IP address" schemes. The fear is that the RIPE NCC will gouge the legacy resource holders either directly or indirectly, "motivating" them to hand back the resource. * The lack of recognition that these addresses were assigned under a different policy. Anecdotal evidence suggests that at one time you would be handed a class-B instead of 4 class-Cs because there was fear of growth of the routing table. Does the RIPE NCC now want to challenge the assignments? In sum, this makes the RIPE NCC appear more as an extorting bully rather than an agent who has the accuracy of the address register as its foremost priority, and this destroys some of the valuable trust they have built in the community over the years. Regards, - Håvard
At 15:36 18/07/2012 +0200, Havard Eidnes wrote:
Hi,
as you may be aware, the RIPE NCC is currently engaged in an activity to establish contact with legacy address space holders, and among other things to set up a contractual relationship between the RIPE NCC and the legacy resource holders.
However, it is my opinion that the current RIPE NCC actions with legacy resource holders is destroying some of the valuable trust they have built in the community over the years.
It has been said that "the RIPE NCC does what the members tell them to do". That does however not appear to be the case for this action, where the RIPE NCC appears to act in a policy-free zone, simply on executive decision. Despite the RIPE NCCs knowledge that work is ongoing to formulate a policy for this area, they are barging ahead, possibly in an attempt to establish a fait accompli.
It is indeed a shame that the RIPE NCC is plowing ahead without a mandate from the membership to be doing this. It is indeed a shame that the hundreds of legacy IP holders now view the RIPE NCC in a totally different light then they did previously. I do not quite understand the urgency the RIPE NCC sees in forging ahead quickly rather than taking the time to discuss the matter in a calm and non-pressured environment. I am indeed clueless as to why they are doing this. -Hank
The message sent to the legacy resource holders does not mention the option which would probably be most preferable to at least most of our customers, namely registering the resources via the LIR at their service provider. One could suspect the RIPE NCC has self-interest in driving up the number of LIRs, to increase the number of paying customers of the RIPE NCC.
Some of the documents about the approach with legacy resource holders has mentioned a "stick and carrot" approach. I'll claim that the stick is needlessly sharp and the carrot reeks of decomposition. Explanation:
* The stick is primarily the "we cannot guarantee in-addr.arpa name service". Without it, a user will in practice be unable to operate mail servers within the affected address space, which would be a severe blow to those who still actively use their address space.
The freezing of the registry data is an inconvenience which will ensure that the accuracy of the data whittles over time, an action initiated by the RIPE NCC no less... Many legacy resource holders have not updated their records in a long time already (many didn't have an actual need to do so), so while inconvenient, it's not as strong a stick as the threat of removal of the in-addr.arpa delegation. It should however be noted that the whittling of the registration data over time also is detrimental for the RIPE community at large, not only for the address space holder.
* What's the carrot? Only the removal of the stick from above? What makes the carrot particularly rotten is several things:
* The open-ended and unliateral application of "all relevant RIPE NCC policies and procedures". The fear would be "we will mire you or your LIR (or both) down in pointless address policy work to document ancient history, and have the RIPE NCC verify (or deny, as the case may be) all assignments done over time" (applicable where address space has been used in PA-fashion). ...or for PI-style assignments, the assignment itself might be challenged. * The highly uncertain status of the charging scheme in the longer term for the legacy resource holders, where the initial proposal to modify today's model had, with no discussion, abolished the "age based discount", and where current discussion is rampant with "payment per IP address" schemes. The fear is that the RIPE NCC will gouge the legacy resource holders either directly or indirectly, "motivating" them to hand back the resource. * The lack of recognition that these addresses were assigned under a different policy. Anecdotal evidence suggests that at one time you would be handed a class-B instead of 4 class-Cs because there was fear of growth of the routing table. Does the RIPE NCC now want to challenge the assignments?
In sum, this makes the RIPE NCC appear more as an extorting bully rather than an agent who has the accuracy of the address register as its foremost priority, and this destroys some of the valuable trust they have built in the community over the years.
Regards,
- Håvard
(excuse the top posting, but I wanted to keep the whole of Havard's email in the thread as it makes some interesting points) Dear Havard, I'm sorry to see that you believe there has been an erosion of trust between yourself and the RIPE NCC. This is certain not the intent. I would just like to make some points on the legacy address space issues you raise below that I hope will help clarify matters. Note that it is not mandatory to register legacy address space. It's completely optional for legacy address space holders to: a. Become a RIPE NCC member; or b. Register their resources with a sponsoring LIR; or c. Remain as they are While the option for a legacy address space holder to become a member of the RIPE NCC is available, the RIPE NCC actively encourages legacy address space holders to register their address space with a sponsoring LIR. As noted in the RIPE NCC's Activity Plan for 2012, "The goal of these activities will be to bring ERX and legacy space registration records up to the same standards of accuracy as address space distributed by the RIPE NCC since 1992." For legacy address space holders who do wish to become RIPE NCC members, the sign-up fee and the membership fee for the coming year is waived. The document you refer to mentioning the "carrot and stick" approach is the Report of the RIPE NCC Charging Scheme Task Force. This task force was made up of RIPE NCC members, RIPE NCC Executive Board members and representatives from the RIPE NCC. The report only makes recommendations to the RIPE NCC Executive Board regarding a proposed Charging Scheme model. To give you some information on the work carried out by the RIPE NCC so far, the Registration Services Department has contacted 145 existing LIRs who hold legacy resources. The responses from those LIRs can be broken down as follows: - 63 LIRs added the address space under their LIR's registration - 24 LIRs said that they were not interested because of the lack of RIPE Policies - 2 returned unused legacy address space - 56 did not reply to the original email or reminder emails A total of 8,513,280 IP addresses were added to the LIRs' registration during this phase of the project. The RIPE NCC recently started to contact legacy address space holders who are not LIRs. All of the information on the RIPE NCC's activities regarding legacy address space are available at: http://www.ripe.net/lir-services/resource-management/legacy-space Best regards, Nigel Chairman RIPE NCC Board On 18/07/2012 14:36, Havard Eidnes wrote:
Hi,
as you may be aware, the RIPE NCC is currently engaged in an activity to establish contact with legacy address space holders, and among other things to set up a contractual relationship between the RIPE NCC and the legacy resource holders.
However, it is my opinion that the current RIPE NCC actions with legacy resource holders is destroying some of the valuable trust they have built in the community over the years.
It has been said that "the RIPE NCC does what the members tell them to do". That does however not appear to be the case for this action, where the RIPE NCC appears to act in a policy-free zone, simply on executive decision. Despite the RIPE NCCs knowledge that work is ongoing to formulate a policy for this area, they are barging ahead, possibly in an attempt to establish a fait accompli.
The message sent to the legacy resource holders does not mention the option which would probably be most preferable to at least most of our customers, namely registering the resources via the LIR at their service provider. One could suspect the RIPE NCC has self-interest in driving up the number of LIRs, to increase the number of paying customers of the RIPE NCC.
Some of the documents about the approach with legacy resource holders has mentioned a "stick and carrot" approach. I'll claim that the stick is needlessly sharp and the carrot reeks of decomposition. Explanation:
* The stick is primarily the "we cannot guarantee in-addr.arpa name service". Without it, a user will in practice be unable to operate mail servers within the affected address space, which would be a severe blow to those who still actively use their address space.
The freezing of the registry data is an inconvenience which will ensure that the accuracy of the data whittles over time, an action initiated by the RIPE NCC no less... Many legacy resource holders have not updated their records in a long time already (many didn't have an actual need to do so), so while inconvenient, it's not as strong a stick as the threat of removal of the in-addr.arpa delegation. It should however be noted that the whittling of the registration data over time also is detrimental for the RIPE community at large, not only for the address space holder.
* What's the carrot? Only the removal of the stick from above? What makes the carrot particularly rotten is several things:
* The open-ended and unliateral application of "all relevant RIPE NCC policies and procedures". The fear would be "we will mire you or your LIR (or both) down in pointless address policy work to document ancient history, and have the RIPE NCC verify (or deny, as the case may be) all assignments done over time" (applicable where address space has been used in PA-fashion). ...or for PI-style assignments, the assignment itself might be challenged. * The highly uncertain status of the charging scheme in the longer term for the legacy resource holders, where the initial proposal to modify today's model had, with no discussion, abolished the "age based discount", and where current discussion is rampant with "payment per IP address" schemes. The fear is that the RIPE NCC will gouge the legacy resource holders either directly or indirectly, "motivating" them to hand back the resource. * The lack of recognition that these addresses were assigned under a different policy. Anecdotal evidence suggests that at one time you would be handed a class-B instead of 4 class-Cs because there was fear of growth of the routing table. Does the RIPE NCC now want to challenge the assignments?
In sum, this makes the RIPE NCC appear more as an extorting bully rather than an agent who has the accuracy of the address register as its foremost priority, and this destroys some of the valuable trust they have built in the community over the years.
Regards,
- Håvard
Dear Nigel, On 18.07.2012, at 21:41, Nigel Titley wrote:
Note that it is not mandatory to register legacy address space. It's completely optional for legacy address space holders to:
a. Become a RIPE NCC member; or b. Register their resources with a sponsoring LIR; or c. Remain as they are
While the option for a legacy address space holder to become a member of the RIPE NCC is available, the RIPE NCC actively encourages legacy address space holders to register their address space with a sponsoring LIR.
that is correct for information published on the webpages, unfortunately it is not the case for the mails the RIPE NCC sent out to holders of legacy space for Phase 3. According to those mails the only two options for the legacy space holders are to become a member and make the world a better place, or not to become a member and have the registry and reverse DNS data for their legacy space frozen. The people participating in RIPE know about the option of a sponsoring LIR obviously, but my best guess is that for most legacy space holders this mail will be the first contact with the RIPE NCC they ever had. Although there is a link to http://www.ripe.net/lir-services/resource-management/legacy-space in this mail, the wording for a first contact mail is a bit strange and almost threatening for my taste. Marcus -- man-da.de GmbH, AS8365 Phone: +49 6151 16-6956 Mornewegstr. 30 Fax: +49 6151 16-3050 64293 Darmstadt, Germany e-mail: ms@man-da.de Geschäftsführer Marcus Stögbauer AG Darmstadt, HRB 94 84
On 19/07/2012 09:49, Marcus Stoegbauer wrote:
Dear Nigel,
On 18.07.2012, at 21:41, Nigel Titley wrote:
Note that it is not mandatory to register legacy address space. It's completely optional for legacy address space holders to:
a. Become a RIPE NCC member; or b. Register their resources with a sponsoring LIR; or c. Remain as they are
While the option for a legacy address space holder to become a member of the RIPE NCC is available, the RIPE NCC actively encourages legacy address space holders to register their address space with a sponsoring LIR.
that is correct for information published on the webpages, unfortunately it is not the case for the mails the RIPE NCC sent out to holders of legacy space for Phase 3. According to those mails the only two options for the legacy space holders are to become a member and make the world a better place, or not to become a member and have the registry and reverse DNS data for their legacy space frozen.
The people participating in RIPE know about the option of a sponsoring LIR obviously, but my best guess is that for most legacy space holders this mail will be the first contact with the RIPE NCC they ever had. Although there is a link to http://www.ripe.net/lir-services/resource-management/legacy-space in this mail, the wording for a first contact mail is a bit strange and almost threatening for my taste.
Marcus, Give me a couple of days to chase this up with the RIPE NCC. The last thing I want to do is for legacy holders to feel threatened or intimidated. Nigel
Note that it is not mandatory to register legacy address space. It's completely optional for legacy address space holders to:
a. Become a RIPE NCC member; or b. Register their resources with a sponsoring LIR; or c. Remain as they are
While the option for a legacy address space holder to become a member of the RIPE NCC is available, the RIPE NCC actively encourages legacy address space holders to register their address space with a sponsoring LIR.
You know that, and I do too, but I suspect that most legacy holders, especially those who are not LIRs already, don't. The letter the RIPE NCC is currently sending as the first contact with the legacy space holders only explicitly mentions options a) and c) above. In reality, if some legacy space is in use, option c) above isn't an option, given the very thinly veiled threat of removal of the in-addr.arpa DNS delegation. So for these holders, it means there is a certain element of coercion involved pushing towards either option a) or b) above. If I've understood correctly, both option a) and b) above involve in effect abolishment of historical grants and contractual submission to all current and future RIR address policies and procedures which are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting what is relevant. No grandfather clauses, acknowledgement of historical rights or explicit limitations anywhere in sight, and no option to amend the template contract imposed by the RIPE NCC. Therefore, this seems to be a unilateral land grab in the policy area by the RIPE NCC. I'm surprised noone appears to see the inherent danger in such an action.
To give you some information on the work carried out by the RIPE NCC so far, the Registration Services Department has contacted 145 existing LIRs who hold legacy resources. The responses from those LIRs can be broken down as follows:
- 63 LIRs added the address space under their LIR's registration - 24 LIRs said that they were not interested because of the lack of RIPE Policies - 2 returned unused legacy address space - 56 did not reply to the original email or reminder emails
A total of 8,513,280 IP addresses were added to the LIRs' registration during this phase of the project.
This shows that the process of establishing a fait accompli is progressing. Of course many will have budged under the pressure imposed by the RIPE NCC. I'm somewhat encouraged that despite this, quite a few LIRs appear to in effect have said "develop a public policy first, and we'll (re-)consider it". Regards, - Håvard
Hi, Giving some background information related to address policy:
If I've understood correctly, both option a) and b) above involve in effect abolishment of historical grants and contractual submission to all current and future RIR address policies and procedures which are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting what is relevant. No grandfather clauses, acknowledgement of historical rights or explicit limitations anywhere in sight, and no option to amend the template contract imposed by the RIPE NCC.
The template is defined in RIPE-452:
--- The details of any such contracts are outside the scope of this document. However, at the minimum, all contracts should include:
• Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date • Notice that the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database • Notice that none of the provider independent resources may be sub-assigned to a third party • Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources • A clear statement that the resources will return by default to the RIPE NCC if • The resource holder cannot be contacted • The annual fee to the LIR is not paid • A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time ---
The first two requirements are what is important according to the activity plan ("The goal of these activities will be to bring ERX and legacy space registration records up to the same standards of accuracy as address space distributed by the RIPE NCC since 1992."), and I don't think anybody objects to that. The next point about sub-assignments is a problem. Current legacy holders don't have any restrictions on what they can or can not do with their address space. This would suddenly limit what legacy holders are allowed to do, and possibly even make their existing network setup break the contract. The next two points about paying the bills and the addresses returning to the RIPE NCC if the bills are not paid also change the rights of the legacy holder. When they don't sign the contract their records in the database are frozen and the RIPE NCC "cannot guarantee the continuation of reverse DNS". If they sign the contract and then not pay the bill they lose all rights to the address space.... The last point is the most obvious problem for legacy holders. Now the legacy holder is subject to no policy at all, and after signing such a contract they are suddenly subject to all current and future RIPE policies. I fully understand that legacy holders don't want to sign such a contract. But more importantly: RIPE-452 is a result of policy proposal 2007-01, and that proposal explicitly excluded ERX resource holders from being required to sign such a contract. Quoting from 2007-01 (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This proposal does not cover number resources marked in the RIPE database as Early Registration (ERX) or NOT-SET. It also does not cover number resources listed in the RIPE database which were assigned by InterNIC or assigned or allocated by other Regional Internet Registries." So, following the acceptance of 2007-01 by the community: if the RIPE NCC requires legacy holders to sign such a contract (contract with sponsoring LIR) they are doing something which directly contradicts an accepted RIPE policy... If any legacy holder already signed such a contract I strongly feel that they should either be given the option to void the contract, or the contract should be declared void automatically. - Sander
Dear colleagues, In Phase 3 of its legacy space project, the RIPE NCC is sending emails to contact legacy address space holders who are not RIPE NCC members and who hold a /16 or more. In the emails we are sending, all three options, including the option to register legacy address space with a sponsoring LIR, are presented to the organisations. However, in the case of contact with three organisations, an email was mistakenly sent that did not mention the option to use a sponsoring LIR. We regret this mistake and apologise sincerely for the confusion and any distress this might have caused. We are contacting the organisations concerned to ensure that the correct message is delivered and that they are aware of all options available to them. The RIPE NCC understands that "freezing" registry entries would be counterproductive and would not help its goal of ensuring registry correctness. The RIPE NCC has no intention of freezing registry entries for legacy resource holders. Also, the RIPE NCC would like to assure legacy address space holders that it has no intention of withdrawing reverse DNS services for legacy address space holders. The certification of address space, however, is available only to RIPE NCC members. Thank you for raising the issue and for giving us the opportunity to clarify these matters. As Marcus has pointed out, the information concerning the project is available on our legacy webpages: http://www.ripe.net/lir-services/resource-management/legacy-space We will update the documentation concerning the project in the coming days to accurately reflect the situation. Again, we apologise for the error and ask that you contact us at <legacy@ripe.net> if you have any questions or concerns. Or let us know via discussion on the list. Best regards, Andrew de la Haye Chief Operations Officer RIPE NCC On 7/19/12 4:11 PM, Sander Steffann wrote:
Hi,
Giving some background information related to address policy:
If I've understood correctly, both option a) and b) above involve in effect abolishment of historical grants and contractual submission to all current and future RIR address policies and procedures which are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting what is relevant. No grandfather clauses, acknowledgement of historical rights or explicit limitations anywhere in sight, and no option to amend the template contract imposed by the RIPE NCC.
The template is defined in RIPE-452:
--- The details of any such contracts are outside the scope of this document. However, at the minimum, all contracts should include:
• Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date • Notice that the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database • Notice that none of the provider independent resources may be sub-assigned to a third party • Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources • A clear statement that the resources will return by default to the RIPE NCC if • The resource holder cannot be contacted • The annual fee to the LIR is not paid • A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time ---
The first two requirements are what is important according to the activity plan ("The goal of these activities will be to bring ERX and legacy space registration records up to the same standards of accuracy as address space distributed by the RIPE NCC since 1992."), and I don't think anybody objects to that.
The next point about sub-assignments is a problem. Current legacy holders don't have any restrictions on what they can or can not do with their address space. This would suddenly limit what legacy holders are allowed to do, and possibly even make their existing network setup break the contract.
The next two points about paying the bills and the addresses returning to the RIPE NCC if the bills are not paid also change the rights of the legacy holder. When they don't sign the contract their records in the database are frozen and the RIPE NCC "cannot guarantee the continuation of reverse DNS". If they sign the contract and then not pay the bill they lose all rights to the address space....
The last point is the most obvious problem for legacy holders. Now the legacy holder is subject to no policy at all, and after signing such a contract they are suddenly subject to all current and future RIPE policies. I fully understand that legacy holders don't want to sign such a contract.
But more importantly: RIPE-452 is a result of policy proposal 2007-01, and that proposal explicitly excluded ERX resource holders from being required to sign such a contract. Quoting from 2007-01 (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This proposal does not cover number resources marked in the RIPE database as Early Registration (ERX) or NOT-SET. It also does not cover number resources listed in the RIPE database which were assigned by InterNIC or assigned or allocated by other Regional Internet Registries."
So, following the acceptance of 2007-01 by the community: if the RIPE NCC requires legacy holders to sign such a contract (contract with sponsoring LIR) they are doing something which directly contradicts an accepted RIPE policy... If any legacy holder already signed such a contract I strongly feel that they should either be given the option to void the contract, or the contract should be declared void automatically.
- Sander
Dear Andrew, Thank you for explaining that apparently there is a communication issue. Sander Steffann raised an important issue in his email: -- But more importantly: RIPE-452 is a result of policy proposal 2007-01, and that proposal explicitly excluded ERX resource holders from being required to sign such a contract. Quoting from 2007-01 (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This proposal does not cover number resources marked in the RIPE database as Early Registration (ERX) or NOT-SET. It also does not cover number resources listed in the RIPE database which were assigned by InterNIC or assigned or allocated by other Regional Internet Registries." -- Unfortunately you haven't responded to this issue yet. Can you please elaborate on this issue? regards, Rogier On 7/19/12 5:03 PM, Andrew de la Haye wrote:
Dear colleagues,
In Phase 3 of its legacy space project, the RIPE NCC is sending emails to contact legacy address space holders who are not RIPE NCC members and who hold a /16 or more.
In the emails we are sending, all three options, including the option to register legacy address space with a sponsoring LIR, are presented to the organisations. However, in the case of contact with three organisations, an email was mistakenly sent that did not mention the option to use a sponsoring LIR.
We regret this mistake and apologise sincerely for the confusion and any distress this might have caused.
We are contacting the organisations concerned to ensure that the correct message is delivered and that they are aware of all options available to them.
The RIPE NCC understands that "freezing" registry entries would be counterproductive and would not help its goal of ensuring registry correctness. The RIPE NCC has no intention of freezing registry entries for legacy resource holders.
Also, the RIPE NCC would like to assure legacy address space holders that it has no intention of withdrawing reverse DNS services for legacy address space holders.
The certification of address space, however, is available only to RIPE NCC members.
Thank you for raising the issue and for giving us the opportunity to clarify these matters. As Marcus has pointed out, the information concerning the project is available on our legacy webpages: http://www.ripe.net/lir-services/resource-management/legacy-space
We will update the documentation concerning the project in the coming days to accurately reflect the situation.
Again, we apologise for the error and ask that you contact us at <legacy@ripe.net> if you have any questions or concerns. Or let us know via discussion on the list.
Best regards,
Andrew de la Haye Chief Operations Officer RIPE NCC
On 7/19/12 4:11 PM, Sander Steffann wrote:
Hi,
Giving some background information related to address policy:
If I've understood correctly, both option a) and b) above involve in effect abolishment of historical grants and contractual submission to all current and future RIR address policies and procedures which are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting what is relevant. No grandfather clauses, acknowledgement of historical rights or explicit limitations anywhere in sight, and no option to amend the template contract imposed by the RIPE NCC.
The template is defined in RIPE-452:
--- The details of any such contracts are outside the scope of this document. However, at the minimum, all contracts should include:
• Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date • Notice that the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database • Notice that none of the provider independent resources may be sub-assigned to a third party • Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources • A clear statement that the resources will return by default to the RIPE NCC if • The resource holder cannot be contacted • The annual fee to the LIR is not paid • A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time ---
The first two requirements are what is important according to the activity plan ("The goal of these activities will be to bring ERX and legacy space registration records up to the same standards of accuracy as address space distributed by the RIPE NCC since 1992."), and I don't think anybody objects to that.
The next point about sub-assignments is a problem. Current legacy holders don't have any restrictions on what they can or can not do with their address space. This would suddenly limit what legacy holders are allowed to do, and possibly even make their existing network setup break the contract.
The next two points about paying the bills and the addresses returning to the RIPE NCC if the bills are not paid also change the rights of the legacy holder. When they don't sign the contract their records in the database are frozen and the RIPE NCC "cannot guarantee the continuation of reverse DNS". If they sign the contract and then not pay the bill they lose all rights to the address space....
The last point is the most obvious problem for legacy holders. Now the legacy holder is subject to no policy at all, and after signing such a contract they are suddenly subject to all current and future RIPE policies. I fully understand that legacy holders don't want to sign such a contract.
But more importantly: RIPE-452 is a result of policy proposal 2007-01, and that proposal explicitly excluded ERX resource holders from being required to sign such a contract. Quoting from 2007-01 (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This proposal does not cover number resources marked in the RIPE database as Early Registration (ERX) or NOT-SET. It also does not cover number resources listed in the RIPE database which were assigned by InterNIC or assigned or allocated by other Regional Internet Registries."
So, following the acceptance of 2007-01 by the community: if the RIPE NCC requires legacy holders to sign such a contract (contract with sponsoring LIR) they are doing something which directly contradicts an accepted RIPE policy... If any legacy holder already signed such a contract I strongly feel that they should either be given the option to void the contract, or the contract should be declared void automatically.
- Sander
Dear Rogier and Sander, Sorry for the late reply, however holiday period started on our side. As you point out, ripe-453 is a RIPE Policy that requires a contractual agreement between End Users of Provider Independent address and the RIPE NCC, either through a sponsoring LIR or directly with the RIPE NCC. The legacy address space project that the RIPE NCC is engaged in lies completely outside the scope of that policy. For the legacy address space project, the RIPE NCC requires a different contract between the legacy address space holder and a sponsoring LIR. This contract establishes that both parties agree on the correctness of the information provided by the legacy address space holder. This contract should not be the one used for ripe-453. Regards, Andrew On Jul 19, 2012, at 5:39 PM, Rogier Spoor wrote:
Dear Andrew,
Thank you for explaining that apparently there is a communication issue.
Sander Steffann raised an important issue in his email: -- But more importantly: RIPE-452 is a result of policy proposal 2007-01, and that proposal explicitly excluded ERX resource holders from being required to sign such a contract. Quoting from 2007-01 (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This proposal does not cover number resources marked in the RIPE database as Early Registration (ERX) or NOT-SET. It also does not cover number resources listed in the RIPE database which were assigned by InterNIC or assigned or allocated by other Regional Internet Registries." --
Unfortunately you haven't responded to this issue yet. Can you please elaborate on this issue?
regards, Rogier
On 7/19/12 5:03 PM, Andrew de la Haye wrote:
Dear colleagues,
In Phase 3 of its legacy space project, the RIPE NCC is sending emails to contact legacy address space holders who are not RIPE NCC members and who hold a /16 or more.
In the emails we are sending, all three options, including the option to register legacy address space with a sponsoring LIR, are presented to the organisations. However, in the case of contact with three organisations, an email was mistakenly sent that did not mention the option to use a sponsoring LIR.
We regret this mistake and apologise sincerely for the confusion and any distress this might have caused.
We are contacting the organisations concerned to ensure that the correct message is delivered and that they are aware of all options available to them.
The RIPE NCC understands that "freezing" registry entries would be counterproductive and would not help its goal of ensuring registry correctness. The RIPE NCC has no intention of freezing registry entries for legacy resource holders.
Also, the RIPE NCC would like to assure legacy address space holders that it has no intention of withdrawing reverse DNS services for legacy address space holders.
The certification of address space, however, is available only to RIPE NCC members.
Thank you for raising the issue and for giving us the opportunity to clarify these matters. As Marcus has pointed out, the information concerning the project is available on our legacy webpages: http://www.ripe.net/lir-services/resource-management/legacy-space
We will update the documentation concerning the project in the coming days to accurately reflect the situation.
Again, we apologise for the error and ask that you contact us at <legacy@ripe.net> if you have any questions or concerns. Or let us know via discussion on the list.
Best regards,
Andrew de la Haye Chief Operations Officer RIPE NCC
On 7/19/12 4:11 PM, Sander Steffann wrote:
Hi,
Giving some background information related to address policy:
If I've understood correctly, both option a) and b) above involve in effect abolishment of historical grants and contractual submission to all current and future RIR address policies and procedures which are deemed to be relevant, with, I'm sure, the RIPE NCC interpreting what is relevant. No grandfather clauses, acknowledgement of historical rights or explicit limitations anywhere in sight, and no option to amend the template contract imposed by the RIPE NCC.
The template is defined in RIPE-452:
--- The details of any such contracts are outside the scope of this document. However, at the minimum, all contracts should include:
• Notice that the LIR is responsible for liaising with the resource holder to keep registration records up-to-date • Notice that the resource holder is obliged to provide up-to-date registration data to the LIR and that some or all of this registration data will be published in the RIPE WHOIS Database • Notice that none of the provider independent resources may be sub-assigned to a third party • Notice that the resource holder is obliged to pay an annual fee to the LIR for the resources • A clear statement that the resources will return by default to the RIPE NCC if • The resource holder cannot be contacted • The annual fee to the LIR is not paid • A clear statement that the use of resources is subject to RIPE policies as published on the RIPE web site and which may be amended from time to time ---
The first two requirements are what is important according to the activity plan ("The goal of these activities will be to bring ERX and legacy space registration records up to the same standards of accuracy as address space distributed by the RIPE NCC since 1992."), and I don't think anybody objects to that.
The next point about sub-assignments is a problem. Current legacy holders don't have any restrictions on what they can or can not do with their address space. This would suddenly limit what legacy holders are allowed to do, and possibly even make their existing network setup break the contract.
The next two points about paying the bills and the addresses returning to the RIPE NCC if the bills are not paid also change the rights of the legacy holder. When they don't sign the contract their records in the database are frozen and the RIPE NCC "cannot guarantee the continuation of reverse DNS". If they sign the contract and then not pay the bill they lose all rights to the address space....
The last point is the most obvious problem for legacy holders. Now the legacy holder is subject to no policy at all, and after signing such a contract they are suddenly subject to all current and future RIPE policies. I fully understand that legacy holders don't want to sign such a contract.
But more importantly: RIPE-452 is a result of policy proposal 2007-01, and that proposal explicitly excluded ERX resource holders from being required to sign such a contract. Quoting from 2007-01 (http://www.ripe.net/ripe/policies/proposals/2007-01/draft): "This proposal does not cover number resources marked in the RIPE database as Early Registration (ERX) or NOT-SET. It also does not cover number resources listed in the RIPE database which were assigned by InterNIC or assigned or allocated by other Regional Internet Registries."
So, following the acceptance of 2007-01 by the community: if the RIPE NCC requires legacy holders to sign such a contract (contract with sponsoring LIR) they are doing something which directly contradicts an accepted RIPE policy... If any legacy holder already signed such a contract I strongly feel that they should either be given the option to void the contract, or the contract should be declared void automatically.
- Sander
Hi Andrew,
Sorry for the late reply, however holiday period started on our side.
No problem!
As you point out, ripe-453 is a RIPE Policy that requires a contractual agreement between End Users of Provider Independent address and the RIPE NCC, either through a sponsoring LIR or directly with the RIPE NCC.
The legacy address space project that the RIPE NCC is engaged in lies completely outside the scope of that policy. For the legacy address space project, the RIPE NCC requires a different contract between the legacy address space holder and a sponsoring LIR.
Ah, I think I looked at the wrong contract template then. Thank you for clearing this up!
This contract establishes that both parties agree on the correctness of the information provided by the legacy address space holder. This contract should not be the one used for ripe-453.
I think the problem here is that there is no clear policy on how to deal with ERX/Legacy space and its holders. A group of ERX/Legacy resource holders and I have been working on a policy proposal on this subject. We will (real soon now) submit the first version to this working group so that we can fill this gap and make sure that we have clear policy for all the resources that RIPE NCC handles. Thanks, Sander
Sander, I, amongst others, am really pleased that policy regarding the legacy resource holders is starting to emerge. Nigel -----Original Message----- From: ncc-services-wg-bounces@ripe.net [mailto:ncc-services-wg-bounces@ripe.net] On Behalf Of Sander Steffann Sent: 10 August 2012 11:54 To: Andrew de la Haye Cc: ncc-services-wg@ripe.net; Andrew de la de la Haye; Nigel Titley; Rogier Spoor Subject: Re: [ncc-services-wg] Destruction of trust Hi Andrew,
Sorry for the late reply, however holiday period started on our side.
No problem!
As you point out, ripe-453 is a RIPE Policy that requires a contractual agreement between End Users of Provider Independent address and the RIPE NCC, either through a sponsoring LIR or directly with the RIPE NCC.
The legacy address space project that the RIPE NCC is engaged in lies completely outside the scope of that policy. For the legacy address space project, the RIPE NCC requires a different contract between the legacy address space holder and a sponsoring LIR.
Ah, I think I looked at the wrong contract template then. Thank you for clearing this up!
This contract establishes that both parties agree on the correctness of the information provided by the legacy address space holder. This contract should not be the one used for ripe-453.
I think the problem here is that there is no clear policy on how to deal with ERX/Legacy space and its holders. A group of ERX/Legacy resource holders and I have been working on a policy proposal on this subject. We will (real soon now) submit the first version to this working group so that we can fill this gap and make sure that we have clear policy for all the resources that RIPE NCC handles. Thanks, Sander
On 10 Aug 2012, at 11:53, Sander Steffann wrote:
I think the problem here is that there is no clear policy on how to deal with ERX/Legacy space and its holders. A group of ERX/Legacy resource holders and I have been working on a policy proposal on this subject. We will (real soon now) submit the first version to this working group so that we can fill this gap and make sure that we have clear policy for all the resources that RIPE NCC handles.
At this time of the year, the phrase "real soon now" needs quite an elastic interpretation. Please find an initial version of our proposal attached. Best regards, Niall O'Reilly
* Niall O'Reilly
Please find an initial version of our proposal attached.
Hi, Having read through very quickly, I'm in general supportive, but I don't think this belongs in the policy text itself: «It is noted that, as of August 2012, commercial domain-name registrars are able to provide services comparable to the basic services defined above at a tax-inclusive retail price of about twenty euro.» It sounds more like rationale to me (although not a very good one, in my opinion). The next two paragraphs suffice as policy. -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com
On 23.08.2012, at 14:12 , Tore Anderson wrote:
* Niall O'Reilly
Please find an initial version of our proposal attached.
Hi,
Having read through very quickly, I'm in general supportive, but I don't think this belongs in the policy text itself:
...
It sounds more like rationale to me (although not a very good one, in my opinion). The next two paragraphs suffice as policy.
There is a lot of such things in the proposal. It would benefit from a very clear separation of rationale, referenced policies, new policy and explanations. Clear and plain policy language should be kept clearly separate from the other parts and should not repeat other existing policy language, but reference it. Daniel
I think Kurtis has already addressed this. I'm assuming that Niall et al will refactor the proposal and submit it through the usual channels. Nigel -----Original Message----- From: ncc-services-wg-bounces@ripe.net [mailto:ncc-services-wg-bounces@ripe.net] On Behalf Of Daniel Karrenberg Sent: 23 August 2012 17:20 To: Tore Anderson Cc: Emilio Madaio; Nigel Titley; ncc-services-wg@ripe.net; Rogier Spoor; Andrew de la de la Haye; Sander Steffann; Andrew de la Haye; Niall O'Reilly Subject: Re: [ncc-services-wg] Policy proposal for services to legacy Internet resource holders On 23.08.2012, at 14:12 , Tore Anderson wrote:
* Niall O'Reilly
Please find an initial version of our proposal attached.
Hi,
Having read through very quickly, I'm in general supportive, but I don't think this belongs in the policy text itself:
...
It sounds more like rationale to me (although not a very good one, in my opinion). The next two paragraphs suffice as policy.
There is a lot of such things in the proposal. It would benefit from a very clear separation of rationale, referenced policies, new policy and explanations. Clear and plain policy language should be kept clearly separate from the other parts and should not repeat other existing policy language, but reference it. Daniel
On 23 Aug 2012, at 17:50, Nigel Titley wrote:
I'm assuming that Niall et al will refactor the proposal and
Soon. If anyone would like to add their early comments to those from Tore and Daniel, they will be welcome off-list or on, and we'll take them into account. Thanks to Tore and Daniel for theirs.
submit it through the usual channels.
Done earlier today. Please, everyone, accept my apologies for not doing so first time. Best regards, Niall O'Reilly
On 23 aug 2012, at 19:16, Niall O'Reilly <Niall.oReilly@ucd.ie> wrote:
On 23 Aug 2012, at 17:50, Nigel Titley wrote:
I'm assuming that Niall et al will refactor the proposal and
Soon. If anyone would like to add their early comments to those from Tore and Daniel, they will be welcome off-list or on, and we'll take them into account.
Thanks to Tore and Daniel for theirs.
I have a proposed clarity I like to see added. The document very briefly talks about how and under what conditions these legacy blocks where allocated. I think the document would benefit with clarifying this a bit further. I.e what's the relationship to the IANA registry, to the IR registry, RFC1174 and RFC1466. What happens if the IETF updates the IPv4 registry with a new RFC etc etc. Best regards, - kurtis -
On 22 aug 2012, at 18:28, Niall O'Reilly <Niall.oReilly@ucd.ie> wrote:
On 10 Aug 2012, at 11:53, Sander Steffann wrote:
I think the problem here is that there is no clear policy on how to deal with ERX/Legacy space and its holders. A group of ERX/Legacy resource holders and I have been working on a policy proposal on this subject. We will (real soon now) submit the first version to this working group so that we can fill this gap and make sure that we have clear policy for all the resources that RIPE NCC handles.
At this time of the year, the phrase "real soon now" needs quite an elastic interpretation.
Please find an initial version of our proposal attached.
Best regards, Niall O'Reilly
So this was somewhat of a mistake. As this is a policy proposal it will be resubmitted the correct way and in the correct format and you will get the usual announcement from Emilio. For the NCC Wg-Chairs : Best regards, - kurtis -
On 22/08/2012 17:28, Niall O'Reilly wrote:
Please find an initial version of our proposal attached.
I've attached some thoughts on this proposal (which I note is formally pre-publication, so these thoughts are premature). These are observations only - I'm not expressing any opinions because it's not appropriate to express an opinion before the PDP formally starts and I haven't finished formulating my opinions yet. If the proposal authors feel that there are any inaccuracies / misrepresentations / omissions here, I'd be happy to be corrected. If it would be more appropriate to wait until this document is formally announced before discussion, then I'm also happy to wait until then. Background: There are just over 3000 ERX registrations listed in the RIPE database. The proposal identifies in a roundabout way that the core problem is the lack of an existing governing contract between the ERX holders and the RIPE NCC and that in order to resolve this, the existing ERX holders should be invited on a no obligation basis to enter into a formal agreement with the RIPE NCC. In return for this invitation, the proposal creates a policy which will copperfasten the service levels which ERX holders were receiving prior to October 2011. There are two sides to the problem. On the one hand, ERX holders obtained address space without a governing contract and have been enjoying the benefits of this for many years. On the other hand, someone is footing the bill for the maintenance and upkeep of this registration data - namely the RIPE NCC membership. Historically, the ERX holders have been happy with this situation as they received all of the privileges of address registration which were available to RIPE-assigned space and none of the responsibilities (i.e. payment). Notably, they were sufficiently happy that no-one saw any need to change the status quo by formalising this situation through a bottom-up policy. Clearly this wasn't working for the RIPE NCC, as they unilaterally withdrew the ability to perform record modifications. This was done without a mandate from the RIPE community or prior notice to the ERX holders. Whatever the rights and wrongs of this situation or how it came about, resolution is clearly necessary. The ERX holders have abruptly been disenfranchised, and the RIPE NCC's responsibilities as steward of these resources are consequently not being carried out. Neither of these positions is tenable as a long term proposition. Policy Resolution: A policy resolution needs to be found which will accommodate the wishes of the ERX holders (right of use / updates / transfers / sale / assignment of rights / contractual certainty), the RIPE community (requirement for responsible stewardship for a RIR), the RIPE NCC (payment for services received, contractual certainty) and the RIPE NCC membership (potential objection of subsidisation of non-members for ongoing services) There is a broad spectrum of potential approaches to resolution, ranging from spontaneous policy proposition by the ERX holders to unilateral action by the RIPE NCC to impose a policy determined by the RIPE community, with the decision making process being based on bottom-up consensus through the PDP, right through to a top-down decision being decided by the dutch legal system. In the absence of any existing agreement between the individual ERX holders and the RIPE NCC, it is not clear what the RIPE NCC's legal obligations are with respect to each individual ERX holder. The Current Proposal: As a side note, it is not clear to what extent this proposal reflects the viewpoints of a representative sample of ERX holders. The proposal suggests the following balance of rights and responsibilities: Rights of ERX holders: - right of use - right to have registration data kept up to date (registrant data, reverse DNS) - right to surrender the assignment - right of transfer / corporate succession / personal succession of assignment under the same terms as enjoyed by the original holder - the right to choose whether or not to enter into a formal contractual relationship with the RIPE NCC (either directly or indirectly) concerning these registrations - the right to choose whether or not to pay the RIPE NCC to maintain these registrations - the right that these rights be unaffected by any other relationship that the ERX holder has with the RIPE NCC - the right that this framework be declared as the basis of any future discussion - the right that these rights be declared as immutable in perpetuity ERX holder responsibilities: - none, unless the ERX holder chooses otherwise - if the ERX holder chooses, then: - payment of fee which is guaranteed to be lower than direct assignment RIPE NCC rights: - the right to charge for RIR services over and above those listed by the proposal as ERX holder rights RIPE NCC responsibilities - to agree explicitly to the rights claimed by the proposal - to maintain the data in the RIPE database - to perform updates / modifications / transfers as directed by ERX holders - to be responsible for ensuring that contact is made with all ERX resource holders - to agree to underwrite any cost associated with implementing this policy which is not recovered under the terms of section 5.5 of the proposal, passing on responsibility and costs to LIRs in the first instance If any of the policy proposers feel that this is unfair / inaccurate summary of the proposal / the situation, or if they feel that there are any omissions, please feel free to correct me. This email is not intended as an opinion piece and should not be read as such; I'm simply trying to understand what is being said in the proposal - it's long, complicated and is a first draft in attempting to deal with a particularly thorny issue which is fraught with political difficulties and legal uncertainties. Nick
On 23/08/2012 22:48, Nick Hilliard wrote:
RIPE NCC rights: - the right to charge for RIR services over and above those listed by the proposal as ERX holder rights
Apologies, I omitted the following: - the right for the RIPE NCC to withdraw a basic service if and only if an equivalent other service is provided, potentially charging the ERX holder for the new service (section 5.1.2) I think there may be a conflict in the proposal here between the proposed rights of the ERX holders (i.e. the NCC must provide the basic services as stated and must not coerce the ERX holder into paying in any circumstance), and this suggestion (the RIPE NCC may completely withdraw a specific service and replace it with something equivalent, and by doing so may potentially coerce the ERX holder into paying for the new service). Or did I read it incorrectly? Nick
On Thu, Aug 23, 2012 at 11:11:04PM +0100, Nick Hilliard wrote:
On 23/08/2012 22:48, Nick Hilliard wrote:
RIPE NCC rights: - the right to charge for RIR services over and above those listed by the proposal as ERX holder rights
Apologies, I omitted the following:
- the right for the RIPE NCC to withdraw a basic service if and only if an equivalent other service is provided, potentially charging the ERX holder for the new service (section 5.1.2)
I think there may be a conflict in the proposal here between the proposed rights of the ERX holders (i.e. the NCC must provide the basic services as stated and must not coerce the ERX holder into paying in any circumstance), and this suggestion (the RIPE NCC may completely withdraw a specific service and replace it with something equivalent, and by doing so may potentially coerce the ERX holder into paying for the new service). Or did I read it incorrectly?
A possible issue one can infer from the outlined text is a future discussion about what comprises what the draft calles "basic services": the means for resource holders to maintain the registry data relating to their resources; publication, of this data and the provisioning of relevant delegation records in the reverse DNS. Variances of this topic are already an occasional matter of RIPE mailing lists discussions. Martin
On 23 Aug 2012, at 23:11, Nick Hilliard wrote:
Apologies, I omitted the following:
- the right for the RIPE NCC to withdraw a basic service if and only if an equivalent other service is provided, potentially charging the ERX holder for the new service (section 5.1.2)
I think there may be a conflict in the proposal here between the proposed rights of the ERX holders (i.e. the NCC must provide the basic services as stated and must not coerce the ERX holder into paying in any circumstance), and this suggestion (the RIPE NCC may completely withdraw a specific service and replace it with something equivalent, and by doing so may potentially coerce the ERX holder into paying for the new service). Or did I read it incorrectly?
Nick, Whether due to your reading or my writing, I can't say, but you did miss the intent. On both sides of the apparent conflict which you identify, I think you've read more into the text than was intended. The point here is about availability of basic services (implicitly from the NCC) or of an equivalent service package (not necessarily from the NCC) at a price for either which is reasonable by reference to the current market price of a comparable service package. I expect that this will be clearer in the next (formally: initial?) draft. I could say more, but it's probably best to wait until the formalities have been respected and we properly have a draft to discuss. Best regards, Niall
At 22:48 23/08/2012 +0100, Nick Hilliard wrote:
There are two sides to the problem. On the one hand, ERX holders obtained address space without a governing contract and have been enjoying the benefits of this for many years. On the other hand, someone is footing the bill for the maintenance and upkeep of this registration data - namely the RIPE NCC membership.
Historically, the ERX holders have been happy with this situation as they received all of the privileges of address registration which were available to RIPE-assigned space and none of the responsibilities (i.e. payment).
I believe if you did an analysis of the 3000 allocations, you would find that many (my estimate - over 1700) are academic allocations and those NRENs are all paying members of RIPE NCC. And they have probably been paying members far longer than 99.9% of the RIPE membership (Janet, Renater, GARR, Surfnet, SWITCH, IUCC, etc.). But lets look at the fees as compared to ARIN: https://www.arin.net/fees/fee_schedule.html Legacy RSA: "ARIN charges a $100 USD annual fee for coverage of legacy resources under the terms of the Legacy Registration Services Agreement (Legacy RSA). Org IDs already paying annual ISP or end user fees do not pay an additional fee to receive Legacy RSA coverage. There is no initial registration fee for legacy applicants, unless a transfer is required." So, adopting a similar policy in RIPE NCC should be easy since there is a precedent. -Hank
On 24 Aug 2012, at 08:25, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
I believe if you did an analysis of the 3000 allocations, you would find that many (my estimate - over 1700) are academic allocations and those NRENs are all paying members of RIPE NCC. And they have probably been paying members far longer than 99.9% of the RIPE membership (Janet, Renater, GARR, Surfnet, SWITCH, IUCC, etc.).
Hank, Are these address blocks registered to the academic institutions or to the nrens? If they are registered as being assigned directly to the institutions, I'm not sure why it's relevant that the nrens are paying members of the ripe ncc when comparing this situation to the arin LRSA. If they are registered to the nrens rather than the academic institutions then I can see that there would be a valid comparison here, which could be relevant if the ripe community were to agree that an arin style LRSA would be an appropriate means of resolving this situation. Nick
At 12:16 24/08/2012 +0100, Nick Hilliard wrote:
I believe if you did an analysis of the 3000 allocations, you would find that many (my estimate - over 1700) are academic allocations and
On 24 Aug 2012, at 08:25, Hank Nussbacher <hank@efes.iucc.ac.il> wrote: those NRENs are all paying members of RIPE NCC. And they have probably been paying members far longer than 99.9% of the RIPE membership (Janet, Renater, GARR, Surfnet, SWITCH, IUCC, etc.).
Hank,
Are these address blocks registered to the academic institutions or to the nrens? If they are registered as being assigned directly to the institutions, I'm not sure why it's relevant that the nrens are paying members of the ripe ncc when comparing this situation to the arin LRSA.
Based on mnt-by, the # of ERX address blocks managed by the top 11 NRENs in Europe: AS786 278 JOM12-RIPE operations@ja.net AS2200 257 GR1378-RIPE RenSVP@Renater.fr AS680 216 DUMY-RIPE no-email [DFN] AS137 166 EV182-RIPE Enzo.Valente@garr.it AS1103 119 SNS1-RIPE netmaster@surfnet.nl AS559 115 WH1101 huber@switch.ch AS696 45 WH1101 huber@switch.ch AS766 32 ER494-RIPE esther.robles@rediris.es AS1101 32 WB311-RIPE Wim.Biemolt@surfnet.nl AS1853 23 AA7477-RIPE admin@aco.net AS378 20 HN293-RIPE hank@efes.iucc.ac.il -Hank
If they are registered to the nrens rather than the academic institutions then I can see that there would be a valid comparison here, which could be relevant if the ripe community were to agree that an arin style LRSA would be an appropriate means of resolving this situation.
Nick
On 25 Aug 2012, at 19:31, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
Based on mnt-by, the # of ERX address blocks managed by the top 11 NRENs in Europe:
mnt-by does not convey registration rights. Or did I miss a whopper of a change in policy recently? Nick
AS786 278 JOM12-RIPE nstitutiooperations@ja.net AS2200 257 GR1378-RIPE RenSVP@Renater.fr AS680 216 DUMY-RIPE no-email [DFN] AS137 166 EV182-RIPE Enzo.Valente@garr.it AS1103 119 SNS1-RIPE netmaster@surfnet.nl AS559 115 WH1101 huber@switch.ch AS696 45 WH1101 huber@switch.ch AS766 32 ER494-RIPE esther.robles@rediris.es AS1101 32 WB311-RIPE Wim.Biemolt@surfnet.nl AS1853 23 AA7477-RIPE admin@aco.net AS378 20 HN293-RIPE hank@efes.iucc.ac.il
-Hank
If they are registered to the nrens rather than the academic institutions then I can see that there would be a valid comparison here, which could be relevant if the ripe community were to agree that an arin style LRSA would be an appropriate means of resolving this situation.
Nick
On 8/26/12 1:02 AM, Nick Hilliard wrote:
On 25 Aug 2012, at 19:31, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
Based on mnt-by, the # of ERX address blocks managed by the top 11 NRENs in Europe:
mnt-by does not convey registration rights. Or did I miss a whopper of a change in policy recently?
For ERX ranges policies are not applicable. MNT-BY is unfortunately the best indicator that's available. Rogier
Nick
AS786 278 JOM12-RIPE nstitutiooperations@ja.net AS2200 257 GR1378-RIPE RenSVP@Renater.fr AS680 216 DUMY-RIPE no-email [DFN] AS137 166 EV182-RIPE Enzo.Valente@garr.it AS1103 119 SNS1-RIPE netmaster@surfnet.nl AS559 115 WH1101 huber@switch.ch AS696 45 WH1101 huber@switch.ch AS766 32 ER494-RIPE esther.robles@rediris.es AS1101 32 WB311-RIPE Wim.Biemolt@surfnet.nl AS1853 23 AA7477-RIPE admin@aco.net AS378 20 HN293-RIPE hank@efes.iucc.ac.il
-Hank
If they are registered to the nrens rather than the academic institutions then I can see that there would be a valid comparison here, which could be relevant if the ripe community were to agree that an arin style LRSA would be an appropriate means of resolving this situation.
Nick
On 26/08/2012 00:09, Rogier Spoor wrote:
On 8/26/12 1:02 AM, Nick Hilliard wrote:
On 25 Aug 2012, at 19:31, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
Based on mnt-by, the # of ERX address blocks managed by the top 11 NRENs in Europe:
mnt-by does not convey registration rights. Or did I miss a whopper of a change in policy recently?
For ERX ranges policies are not applicable.
MNT-BY is unfortunately the best indicator that's available.
Rogier, I suspect (strongly) that the individual academic institutions would feel that the address space is registered to them, not to the nrens. Nick
At 12:26 27/08/2012 +0100, Nick Hilliard wrote:
On 26/08/2012 00:09, Rogier Spoor wrote:
On 8/26/12 1:02 AM, Nick Hilliard wrote:
On 25 Aug 2012, at 19:31, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
Based on mnt-by, the # of ERX address blocks managed by the top 11 NRENs in Europe:
mnt-by does not convey registration rights. Or did I miss a whopper of a change in policy recently?
For ERX ranges policies are not applicable.
MNT-BY is unfortunately the best indicator that's available.
Rogier,
I suspect (strongly) that the individual academic institutions would feel that the address space is registered to them, not to the nrens.
Nick
DDN.MIL NIC would tend to disagree with your statement (similar emails were sent back in the "old" days to most NRENs since we were the Internet pioneers):
Date: Fri, 26 Jul 91 14:00:26 PDT From: HOSTMASTER@NIC.DDN.MIL Subject: Re: Internet network number template Sender: SHARON@NIC.DDN.MIL To: HANK%VM.TAU.AC.IL@TAUNIVM.TAU.AC.IL cc: sharon@NIC.DDN.MIL, hostmaster@NIC.DDN.MIL Reply-To: HOSTMASTER@NIC.DDN.MIL In-Reply-To: Message from "Hank Nussbacher <HANK%VM.TAU.AC.IL@TAUNIVM.TAU.AC.IL>" of Wed, 24 Jul 91 15:44:58 PDT Message-ID: <12704514128.56.SHARON@NIC.DDN.MIL>
Hank,
In view of your role as the network coordinator for the universities and governmental departments in Israel, we here at the Network Information Center feel it would be appropriate if you could serve as the IP number delegating authority for the country of Israel.
Basically this means that any applicaton we recieve from Israel will be forwarded to you for IP number assignment from your allotment of class C and B blocks.
The delegating authority receives the applications, assigns a number or numbers and then sends us the information so that we can update our database (this is where the form came in that I sent to you in our last conversation).
We have several others like yourself who have received large blocks of numbers and serve as delegating authorities for their respective countries. Some do this on and "official" basis and some on an "unofficial" basis. The difference between the two is that in the "unofficial" situations the delegators wish to use the numbers for specific areas of concern (eg only centers of research) and not for any company or organization that desires a network number and/or network connection.
At the present time we have "official" delegating authorities for the countries of Canada, Mexico, Italy, and the Netherlands. We have "unofficial" delegating authorities for the countries of France, Germany, and Sweden.
If you would like to contact any of the authorities listed above for more details, let me know and I will forward their names and addresses to you.
For the time being since you did mention that these numbers are to be used for university and for various Ministry offices, may we forward any requests from Israel that we receive back to you for processing?
I have taken the liberty of naming the blocks of numbers ISRAELB-BLOCK and ISRAELC-BLOCK (totally unimaginative I know but we had to use something :-)) If you could think of some other identifier that would best fit the network system please let me know and I'll change the name immediately.
ISRAELB-BLOCK 147.233 - 147.237 5 B's
ISRAELC-BLOCK 192.114.1 - 192.114.254 192.115.1 - 192.115.254 192.116.1 - 192.116.254 192.117.1 - 192.117.254 192.118.1 - 192.118.254 5 Blocks of C's
Thank you for your cooperation.
Regards Sharon An/Hostmaster
On 28 Aug 2012, at 17:42, Hank Nussbacher wrote:
DDN.MIL NIC would tend to disagree with your statement (similar emails were sent back in the "old" days to most NRENs since we were the Internet pioneers)
Hank, that may well be have been true for you. As your email shows. However my version of this truth is even older and very different from yours. The Class B I arranged for my university in the late 1980s was never, ever anything to do with the NREN of that era. This was true for all the UK universities who dabbled in TCP/IP back then. At that time, the NREN was downright hostile to this TCP/IP heresy and we were supposed to only use X.25 based protocols until the transition to OSI was completed. CompSci departments could do TCP/IP over their own ethernets but this was *forbidden* on the WAN (and in some cases, the campus LAN too). Sometimes, it was the Internet pioneers in CompSci or EE departments who got the space from SRI, not even the university itself. Anyone interested in this ancient history can take a look at http://www.uknof.org.uk/uknof7/Reid-History.pdf So the upshot of all this is there's no "one size fits all" answer. In some cases ERX space will have been doled out by the NREN. In others, it won't.
On 28/08/2012 17:42, Hank Nussbacher wrote:
DDN.MIL NIC would tend to disagree with your statement (similar emails were sent back in the "old" days to most NRENs since we were the Internet pioneers):
Hank, Like all windows into the past, the DDN's email prompts more questions than it answers. The thing that immediately jumps out is that if IUCC was acting as a de-facto national internet registry at the time and registered IP addresses on behalf of all Israeli users, not just those in the academic community, then does IUCC maintain some sort of beneficial claim of registration over subnets of the blocks you list - the sort of claim that would entitle you to say that because this was IUCC space rather than IUCC member space, that it really ought to be covered under IUCC's LIR membership for any future potential argument about a RIPE ERX policy? E.g. if ECI Telecom or Bezeq (who received 147.234.0.0/8 and 147.235.0.0/8 respectively, both of which came out of ISRAELB-BLOCK) were to state that their ERX address blocks belonged absolutely to them and that IUCC had no claims whatsoever over them, what would IUCC's position be? This is of course a matter for IUCC and ECI Telecom / Bezeq to resolve. But let's say that IUCC admitted that it had no claim to Bezeq's address block, then where would IUCC stand on 147.233.0.0/8 which is registered to the Open University? Would IUCC's position be that this is different just because they're a member of IUCC. If so, why? I can't see any clear answer here. Maybe you reached an explicit agreement with OpenU about this, but that would be outside the context of your statement about DDN-NIC above? Alternatively, could IUCC feasibly claim that it had a beneficial interest in Bezeq's block: 147.235.0.0/8? I really doubt it. I'm not fishing for answers to these specific questions, btw. I'm interested in the general issue: who is the ultimate assignee of the ERX blocks which were handed out via the NRENs and what claims are both they and the NRENs making over it? And if there is a precedent for tacitly agreeing that e.g. commercial / governmental ERX assignees are not subject to any NRENs' beneficial claims over the address space for whatever reason, then on what basis are you claiming that the NRENs have any beneficial claim over their members' address space? When I was registering address space from the InterNIC in the early 1990s, the address space was registered directly, and it was not done via a local agent (e.g. HEAnet in the case of Ireland). There was a clear understanding in all cases that the address space was registered to the individual assignee regardless of whether the registration was handled directly by the assignee or via a service provider (both HEAnet/as1213 and IEUnet/as2110 provided this service at the time). There was also a clear understanding that this address space would remain with the assignee, where-ever they happened to be connected to. There was no concept that the address space would be anything other than provider independent - in fact the idea was anathema. At least this was the case in Ireland - Israel may have been different, but I see no evidence of it in the email that you received from the DDN-NIC, regardless of talk of "your allotment". It looks much more like IUCC was acting as the equivalent of a modern day National Internet Registry of the form they currently deploy in east asia (which also receives "allocations" from apnic), rather than a pre-RIR-era LIR handling modern style PA address space. Nick
At 23:20 28/08/2012 +0100, Nick Hilliard wrote:
On 28/08/2012 17:42, Hank Nussbacher wrote:
DDN.MIL NIC would tend to disagree with your statement (similar emails were sent back in the "old" days to most NRENs since we were the Internet pioneers):
Hank,
Like all windows into the past, the DDN's email prompts more questions than it answers.
The thing that immediately jumps out is that if IUCC was acting as a de-facto national internet registry at the time and registered IP addresses on behalf of all Israeli users, not just those in the academic community, then does IUCC maintain some sort of beneficial claim of registration over subnets of the blocks you list - the sort of claim that would entitle you to say that because this was IUCC space rather than IUCC member space, that it really ought to be covered under IUCC's LIR membership for any future potential argument about a RIPE ERX policy?
Only IP space that remains maintained under our LIR/NREN (il.iucc).
E.g. if ECI Telecom or Bezeq (who received 147.234.0.0/8 and 147.235.0.0/8 respectively, both of which came out of ISRAELB-BLOCK) were to state that their ERX address blocks belonged absolutely to them and that IUCC had no claims whatsoever over them, what would IUCC's position be?
Since all that IP space is no longer under our LIR, we have no claims to it. We gladly allocated that IP space to them 20+ years ago and those blocks are now listed under different LIRs that have nothing to do wth IUCC.
This is of course a matter for IUCC and ECI Telecom / Bezeq to resolve. But let's say that IUCC admitted that it had no claim to Bezeq's address block, then where would IUCC stand on 147.233.0.0/8 which is registered to the Open University? Would IUCC's position be that this is different just because they're a member of IUCC. If so, why?
Yes, our view is different on that block since it remained as a member of IUCC since the time it was allocated to them.
I can't see any clear answer here. Maybe you reached an explicit agreement with OpenU about this, but that would be outside the context of your statement about DDN-NIC above?
Alternatively, could IUCC feasibly claim that it had a beneficial interest in Bezeq's block: 147.235.0.0/8? I really doubt it.
We don't have any claim to their /16.
I'm not fishing for answers to these specific questions, btw. I'm interested in the general issue: who is the ultimate assignee of the ERX blocks which were handed out via the NRENs and what claims are both they and the NRENs making over it?
My answer would be "Whatever is decided upon by the RIPE membership and not unilaterally by RIPE NCC management". But your initial comment of "On the one hand, ERX holders obtained address space without a governing contract and have been enjoying the benefits of this for many years. On the other hand, someone is footing the bill for the maintenance and upkeep of this registration data - namely the RIPE NCC membership." is clearly wrong in many cases since il.iucc has been "footing the bill" for all ERX space listed under its LIR.
And if there is a precedent for tacitly agreeing that e.g. commercial / governmental ERX assignees are not subject to any NRENs' beneficial claims over the address space for whatever reason, then on what basis are you claiming that the NRENs have any beneficial claim over their members' address space?
Because in our case, the members (read universities), are the "owners" of the NREN. Legally speaking.
When I was registering address space from the InterNIC in the early 1990s, the address space was registered directly, and it was not done via a local agent (e.g. HEAnet in the case of Ireland). There was a clear understanding in all cases that the address space was registered to the individual assignee regardless of whether the registration was handled directly by the assignee or via a service provider (both HEAnet/as1213 and IEUnet/as2110 provided this service at the time). There was also a clear understanding that this address space would remain with the assignee, where-ever they happened to be connected to. There was no concept that the address space would be anything other than provider independent - in fact the idea was anathema.
At least this was the case in Ireland - Israel may have been different, but I see no evidence of it in the email that you received from the DDN-NIC, regardless of talk of "your allotment". It looks much more like IUCC was acting as the equivalent of a modern day National Internet Registry of the form they currently deploy in east asia (which also receives "allocations" from apnic), rather than a pre-RIR-era LIR handling modern style PA address space.
That might be true for the allocation I listed above as an example, but there were other, even larger allocations, that were assigned specifically to IUCC for sub-allocation to its university members. -Hank
Nick
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just my 2ct: not any University or worse religous campaign should block a /8 or /16 without having to state HERE&NOW why and for what they really need&use it. They need exactly 1 IP for every 65536 concurrently active student to NAT and 1 for each public service at most, lets put a /22 for infra on top and then we're fine.. We have to do either I guess, at least we do, according to RIPE-policys. So we're playing with different cards here, legacy holders are being asked "what might be a nice proposal they like", I'm not asked what "might be nice for me" Regardless of legal stuff it's IMHO easy, it's basically just unassigned space, its getting routed or -well then- not.. AFAIK there's no global law on which IP's I have to route as ISP.. I don't see any "right" just on the fact address-assignment was done very different and generous 20yrs ago. It was a nice time being able to assign any fridge on the campus an IPv4 but its just over now. Times are changing, legacy resource-holders have to accept that. Done worldwide this would fully obsolete the whole IPv4 address-space discussion for many, many years! IMHO the problem isnt that we dont have enough IPv4 addresses but that thei're unequally distributed and - worse- most of them useless wasted in small networks that claim to be big like universitys just because they "have" them.. In other words, regarding the threads' context: Might sound hard but IMHO legacy resource holders should be given facts they have to agree with or leave (BGP), not nice proposals with "opt-in" wether they want to and "hmm lets talk about a little". Michael - -- Mit freundlichen Grüssen Michael Markstaller Elaborated Networks GmbH www.elabnet.de Lise-Meitner-Str. 1, D-85662 Hohenbrunn, Germany fon: +49-8102-8951-60, fax: +49-8102-8951-80 Geschäftsführer: Stefan Werner, Michael Markstaller Amtsgericht München HRB 125120, Ust-ID: DE201281054 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA9awAACgkQaWRHV2kMuAKmAgCcDQwkn9xH0g/Ng3Qh5XTVdyND b2MAoJtovdGTag7Njh2XMVro1CuC9Ow0 =RpTC -----END PGP SIGNATURE-----
or worse religous campaign should Sorry I mixed up iucc with some strange "church" in US, please delete
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.08.2012 03:06, Michael Markstaller wrote: that part.. Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA9dacACgkQaWRHV2kMuAIfiQCggS9GI/eDvFLwL8kGbP/lsegC KEEAoOfg65TbJazHxBBJuC9SCXkBh5PT =zm8c -----END PGP SIGNATURE-----
Hi, On Wed, Aug 29, 2012 at 03:06:08AM +0200, Michael Markstaller wrote:
Just my 2ct: not any University or worse religous campaign should block a /8 or /16 without having to state HERE&NOW why and for what they really need&use it. They need exactly 1 IP for every 65536 concurrently active student to NAT and 1 for each public service at most, lets put a /22 for infra on top and then we're fine..
This is not how the old Internet used to work, and it is not how it works today - nobody is forced to use NAT by the RIRs, and that's how it must be (*and* it has nothing to do with the question of ERX space governance whatsoever).
We have to do either I guess, at least we do, according to RIPE-policys. So we're playing with different cards here, legacy holders are being asked "what might be a nice proposal they like", I'm not asked what "might be nice for me"
ERX space has not been given out under RIPE policies, so they do not apply. Period. There is no law, legal contract, or anything else that would make RIPE policies automagically apply to ERX space (and even *then*, there would not be any RIPE policy forcing a user of IP address space to use NAT if they do not want to). [..]
Done worldwide this would fully obsolete the whole IPv4 address-space discussion for many, many years!
It would solve nothing. If people insist on cementing their IPv4 world for a few more years, they would have *more* stuff to move to IPv6 in the long run - nothing solved. Gert Doering -- NetMaster -- 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 (89) 32356-444 USt-IdNr.: DE813185279
On 29 Aug 2012, at 10:05, Gert Doering wrote:
ERX space has not been given out under RIPE policies, so they do not apply. Period. There is no law, legal contract, or anything else that would make RIPE policies automagically apply to ERX space
+1000. It's a great pity the recent policy proposal doesn't use those very words.
On 29.08.2012 11:18, Jim Reid wrote:
On 29 Aug 2012, at 10:05, Gert Doering wrote:
ERX space has not been given out under RIPE policies, so they do not apply. Period. There is no law, legal contract, or anything else that would make RIPE policies automagically apply to ERX space
+1000.
Me too.
It's a great pity the recent policy proposal doesn't use those very words.
Sneak it in as soon as it's formally up. :-) Best, -C.
naive question before we switch terms. is erx == legacy i.e. pre-ncc? no strange corner cases? randy
On Wed, Aug 29, 2012 at 05:07:14PM +0700, Randy Bush wrote:
naive question before we switch terms. is
erx == legacy
i.e. pre-ncc? no strange corner cases?
I'd guess there are corner cases if you take 'pre ncc' literally. 1992/3 there were 'registries of last resort' and I'm not sure those pools were solely filled by the NCC. There was also a famous, then, /8 assignment, the mechanics of which would be interesting to research. -Peter
naive question before we switch terms. is erx == legacy i.e. pre-ncc? no strange corner cases? I'd guess there are corner cases if you take 'pre ncc' literally. 1992/3 there were 'registries of last resort' and I'm not sure those pools were solely filled by the NCC. There was also a famous, then, /8 assignment, the mechanics of which would be interesting to research.
i think we need to agree on a noun to denote exactly those allocations which were issued pre-ncc and are currently outside the ncc membership and policy space. because arin does not have erx space per se, i am used to the term 'legacy' but am happy with anything. randy
On 29/08/2012 12:07, Randy Bush wrote:
naive question before we switch terms. is erx == legacy i.e. pre-ncc? no strange corner cases? I'd guess there are corner cases if you take 'pre ncc' literally. 1992/3 there were 'registries of last resort' and I'm not sure those pools were solely filled by the NCC. There was also a famous, then, /8 assignment, the mechanics of which would be interesting to research. i think we need to agree on a noun to denote exactly those allocations which were issued pre-ncc and are currently outside the ncc membership and policy space.
because arin does not have erx space per se, i am used to the term 'legacy' but am happy with anything.
I think pretty well everyone is happy with "legacy", apart from maybe Jim :-) Nigel
Randy, On Wednesday, 2012-08-29 17:07:14 +0700, Randy Bush <randy@psg.com> wrote:
naive question before we switch terms. is
erx == legacy
i.e. pre-ncc? no strange corner cases?
ERX stands for "early registration transfer". It was the inter-RIR project (I believe between the RIPE NCC, APNIC, and ARIN) designed to make life easier by getting these out of the ARIN database if they made more sense elsewhere. IIRC, the motivation is that it was a pain for people to deal with ARIN if they were many time zones away, and separated by cultural differences. So, if you got a /16 from SRI back in 1990 but your network is in Denmark, then you probably already deal with the RIPE NCC for other things and would prefer not to have to figure out yet another confusing bureaucracy for updating contact and reverse DNS details on that one network. Plus it means that ARIN only has to deal with Americans, which I guess they like. ;) Looking at it from ARIN's point of view, they initially inherited all of their addresses from Network Solutions, so everything pre-1998 could be considered "legacy". From the RIPE NCC's point of view, these were actively transferred in during 2002, so I'm not sure the same term applies, although I suppose it is as good as any other. For the record, I think the treatment - both now and proposed - of ERX space is fundamentally unfair. OTOH, I also don't think it really matters too much in the long run, and a little unfairness is not the worst thing in the world. :) -- Shane
It's a great pity the recent policy proposal doesn't use those very words.
the forces of anti-terseness prevailed :) actually, i suspect it was an attempt at softer manners. randy
On 29/08/2012 10:18, Jim Reid wrote:
On 29 Aug 2012, at 10:05, Gert Doering wrote:
ERX space has not been given out under RIPE policies, so they do not apply. Period. There is no law, legal contract, or anything else that would make RIPE policies automagically apply to ERX space
+1000.
It's a great pity the recent policy proposal doesn't use those very words.
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space? I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all? Nigel
if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all?
because the founding fathers and mothers, who have been quietly minding their own business for a couple of decades received nasty letters from the ncc? because the founding partents actually are trying to be part of the family of their children and grandchildren? randy
if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all? because the founding fathers and mothers, who have been quietly minding their own business for a couple of decades received nasty letters from the ncc? The person at the NCC who sent those letters has had a sharp kick up the
On 29/08/2012 11:14, Randy Bush wrote: posterior.
because the founding partents actually are trying to be part of the family of their children and grandchildren?
Indeed... but I was asking a more fundamental question. If the PDP has no jurisdiction over the legacy holders then why are the legacy holders invoking a process which they are avowing has no jurisdiction over them? Please understand this is a somewhat mischievious question, but one that I feel needs to be answered. Nigel
randy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all? because the founding partents actually are trying to be part of the family of their children and grandchildren? Indeed... but I was asking a more fundamental question. If the PDP has no jurisdiction over the legacy holders then why are the legacy holders invoking a process which they are avowing has no jurisdiction over them?
the pdp may have no current juristiction. but what is attempting to be negotiated is for the pdp to have juristiction. do you have a suggestion for a different approach/venue?
Please understand this is a somewhat mischievious question, but one that I feel needs to be answered.
all taken in good humor and assuming good intent. we have a wonderful opportunity to take the high ground here, maintain humor, assume the best of intent, and set a civilized example. randy, pgp signing because some will not believe i wrote that :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/> iQEcBAEBCgAGBQJQPfkdAAoJEMzMBey4OgLtPt0IAKUj1JjtfD9qIAmldYue94bO FgRooqSYvJQn5y5kSuA5+7fqr/r/DK3Si17tWQy7qVSBHoH5eVhwOn5XmxInYWNt JnxJn09keIxInpC8yNKTktMuvtK45jWGPEnWw1qhgfDyWYdYE7hwH9HRcEY/egbo IQrnfR1P45P+fD7197fFlBv0YQoGBKMn2ElBgf0e4QmUfs+isKIJ7KWa9+5qT+Bt NdjEgsF9IB7w+r4RmDD/uRe7p5HCuKJ7VkRTCImGXhiVNF7+cHenM8nIztZhpEbj Hou3VBeDvA1aWTxiRqdX3nItTPH6S6pI36JvRvBs2v2ZmEN2QH381ggu1aYd/68= =xLHU -----END PGP SIGNATURE-----
On 29/08/2012 12:12, Randy Bush wrote:
the pdp may have no current juristiction. but what is attempting to be negotiated is for the pdp to have juristiction. do you have a suggestion for a different approach/venue?
Now this is starting to make sense. In which case I think we need to have a little reworking of the proposal.
Please understand this is a somewhat mischievious question, but one that I feel needs to be answered. all taken in good humor and assuming good intent. we have a wonderful opportunity to take the high ground here, maintain humor, assume the best of intent, and set a civilized example. Yes, and I'd like us to succeed. I think everyone here owes a great debt to the legacy holders (and bear in mind that I was one). Without their work we'd be wallowing in an OSI mess built on top of X25.
randy, pgp signing because some will not believe i wrote that :) I can't think why :-)
Nigel
Hi Nigel, On 29.08.2012 12:08, Nigel Titley wrote:
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space? I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all?
maybe it should be looked at the other way round: that legacy space holders as good netizens want to unilaterally move this address space under a policy, given that the policy serves their needs and views? Best, Carsten
On 29/08/2012 11:18, Carsten Schiefner wrote:
Hi Nigel,
On 29.08.2012 12:08, Nigel Titley wrote:
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space? I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all?
maybe it should be looked at the other way round: that legacy space holders as good netizens want to unilaterally move this address space under a policy, given that the policy serves their needs and views? Well, actually the proposal explicitly precludes moving the address space under normal address policy. It explicitly says that "...[such future revisions] must never restrict the rights of Legacy Resource Holders to their legacy resources."
Nigel
Hi Nigel, On 29.08.2012 13:59, Nigel Titley wrote:
maybe it should be looked at the other way round: that legacy space holders as good netizens want to unilaterally move this address space under a policy, given that the policy serves their needs and views? Well, actually the proposal explicitly precludes moving the address space under normal address policy. It explicitly says that "...[such future revisions] must never restrict the rights of Legacy Resource Holders to their legacy resources."
that is why I wrote "under _A_ policy" - that doesn't necessarily mean normal address policy. :-) Best, -C.
Hi,
Well, actually the proposal explicitly precludes moving the address space under normal address policy.
I think that when a legacy resource holder wants to be treated as a normal LIR and wants their resources to be treated as non-legacy resources then that should be possible. Once they choose to do that all normal policies start to apply. Sander
[This is said on personal title of someone involved with Internet Number Registration for quite some time.] Can we take a step back agree on definitions and community goals before we continue this discussion? In my book the community goals for IPv4 address space registration are a correct, current and comprehensive registry of who hold/uses the address space. Rob Blokzijl has written this up nicely in ripe-495 with a little help from yours truly. Now that the times of distributing from the unallocated pool of iPv4 addresses are coming to an end, it becomes even more important to maintain such a registry and to make it attractive for address space holders/users to maintain it. Should we fail to maintain such a registry, the consequences range from making it more difficult to track down criminals via hampering operational coordination to balkanisation of the IPv4 Internet. I am sure that participants on this list understand that a bad registry is harmful to them and the community at large. ripe-495 proposes principles for registration policies. Go read it. It is only three pages long and starts from scratch. Philosophically there are multiple ways to legitimise a registry of IP number resources: one may argue that registration authority passes down from the IANA or one can argue that the authority is derived bottom-up from the participants in inter-domain routing or one can argue that it is the RIPE community with its open, transparent and accessible processes that legitimises the RIPE NCC registry. Personally I consider a mixture of these factors to define the de-facto legitimacy of the RIR registries. In practice there is consensus that RIR policies govern registration of the address space that has been distributed via the RIRs. This also includes that changes to RIR policies apply to all such address space. The policies are maintained in an open, transparent and accessible way. The policies are implemented by the RIRs in a professional and neutral way. This is governed by formal agreements between the LIRS/PI holders and the RIR and then transitively down from the LIRs. All this provides security and stability to address space holders/users as well as a correct, current and comprehensive registry to everyone. Then there is "legacy" address space from before the establishment of the RIRs and their policy processes. The registration goals also apply to this address space. However there are no formal agreements and no formal policies. Registrations for much of this address space are also less correct, current and comprehensive than non-legacy registrations. I do not at all critisise those responsible at the time! Quite the opposite. They were providing a community service with little means and in-lieu of doing more exiting things. A small fraction of the IPv4 address space is their "legacy". Please do not confuse legacy space with ERX space. See the post-scriptum for an explanation of ERX space. In order to keep the IPv4 registry comprehensive, current and correct, the RIRs have always encouraged legacy address holder/users to register their address space. The RIRs are also cooperating to reach these goals for legacy address space, see the post-scriptum for an example. The RIPE community has carefully avoided to make legacy address space subject to address space *distribution* policies, such as utilisation criteria. However *registration* policies have been applied to any registrations made as far as the technical operation of the registry is concerned. The community regards good registration to be more important than recovering some address space that might be under-used according to current policies. So what we have to decide as a community is: under which policies does the RIPE community allow legacy space holders to register their address space in the RIPE Internet Number registry. Nothing more, nothing less. All other questions are secondary. Resolving conflicts about the holdership/use of the address space is a non issue. Past agreements about allocation of address space are a non issue. Future agreements about transfers are a non-issue. If there is a conflict about who holds/uses address space, then we need to decide what to do in terms of registration. We can decide to help resolving conflictes, but that is another matter. In my opinion looking for past agreements concerning legacy address space between registrants and IANA or "INTERNIC", "SRI-NIC" or Santa Claus is a waste of time. We have to decide what we register. ripe-495 gives guidance about registration policies, also for legacy space. Let us work with that guidance in mind to define under which conditions registrations for legacy address space should be made and maintained in the RIPE Internet Number registry. Let us not waste time with arguments that are not helpful to make that decision. Daniel PS: Early this century the RIRs, on request of their communities, set up an activity to make registration of legacy address space more correct, current and comprehensive. It was called ERX (Early Registration Transfers). Its stated goal was to move existing registrations of legacy address space to a RIR that was close to the user and verify those registrations at the same time. Goal: correct any errors, get current information registered, make the registries more comprehensive and make it easier to maintain the registrations: "This will enable resource holders to maintain all their records in one database and End Users to interface with just one RIR for all database and reverse delegation matters. This effort will also help to locate address holders and recover unused or underutilised address space." It was explicitly not a goal of ERX to bring the legacy space under the RIR policies in any other respect than those governing the technical operation of the registry. It was stated however that ERX registration holders might be asked to share the operational costs of the registry should the community decide that at a future time. All this has been communicated and discussed by the community at the time. In practice most legacy space was registered with ARIN since ARIN had inherited the registration database from the legacy days and most of those were in use in the ARIN region. So ERX moved registrations from ARIN to other RIRs, mostly to the RIPE NCC. The address space covered by ERX registration transfers is called ERX space. It is only part of the total legacy space. ERX space is the part of legacy space for which registrations have been transferred between RIRs as part of ERX.
in the interest of minimizing abuse of my being an old dog pushing my altzheimer inspired view of the past, i will indulge in quoting more original sources for a bit of perspective on the early internic. http://mailman.postel.org/pipermail/internet-history/2009-August/000899.html randy
Hi Nigel,
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space?
IANAL, but I think that would not be legally possible.
I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all?
If it was about address policy I would have definitely pulled the proposal towards APWG. This is about the RIPE NCC providing services like the RIPE database and reverse DNS. That is why this policy proposal is in the NCC-Services WG. - Sander
Hi, On Wed, Aug 29, 2012 at 11:08:27AM +0100, Nigel Titley wrote:
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space?
I don't think so. APWG policy governs under which rules the RIPE NCC gives out (and possible takes back from) internet numbers from the RIPE NCC "pool" to "consumers" - and this sort of obviously only applies to numbers that the RIPE NCC has been given authority over, via the IETF->IANA->RIPE NCC chain of delegation.
I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all?
Now, the RIPE NCC provides services to legacy address space holders that happen to be in the RIPE service region: - RIPE database and routing registry "who 'owns' it and who is authorized to announce it?" - reverse DNS delegation - potentially: RPKI certificates due to the way RPSL-authentication and DNS tree'ing work, this is not easy to do in a non-hierarchical structure, so "having this done by the RIPE NCC" makes sense from a technical point of view. OTOH, I can see that the NCC wants to see some money in exchange for the expenses running all this (and that seems to make sense as well :-) ). Now, the policy proposal raised here is not an *address space* policy proposal, but an *ncc service* policy proposal - which governs the way the NCC runs their, uh, services. And I think this is a reasonable approach - find something that the ERX holder community and the RIPE NCC is happy with, walk it through an open consensus process, and then nobody can argue that the RIPE NCC is going out and bullying/blackmailing ERX holders over their addresses... (As far as I understand the system, the ERX space would still not be part of the "normal" APWG policy regime - like "RIPE *address* policies have no influence on how the addresses are distributed by the holder's organizationo to 3rd parties" and "no audits", etc.) Gert Doering -- NetMaster -- 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 (89) 32356-444 USt-IdNr.: DE813185279
Fully agree! Having a policy in place for services, will improve access to legacy holders, but won't force *all* legacy holders to use those services... Regards, Carlos On Wed, 29 Aug 2012, Gert Doering wrote:
Hi,
On Wed, Aug 29, 2012 at 11:08:27AM +0100, Nigel Titley wrote:
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space?
I don't think so.
APWG policy governs under which rules the RIPE NCC gives out (and possible takes back from) internet numbers from the RIPE NCC "pool" to "consumers" - and this sort of obviously only applies to numbers that the RIPE NCC has been given authority over, via the IETF->IANA->RIPE NCC chain of delegation.
I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all?
Now, the RIPE NCC provides services to legacy address space holders that happen to be in the RIPE service region:
- RIPE database and routing registry "who 'owns' it and who is authorized to announce it?" - reverse DNS delegation - potentially: RPKI certificates
due to the way RPSL-authentication and DNS tree'ing work, this is not easy to do in a non-hierarchical structure, so "having this done by the RIPE NCC" makes sense from a technical point of view.
OTOH, I can see that the NCC wants to see some money in exchange for the expenses running all this (and that seems to make sense as well :-) ).
Now, the policy proposal raised here is not an *address space* policy proposal, but an *ncc service* policy proposal - which governs the way the NCC runs their, uh, services. And I think this is a reasonable approach - find something that the ERX holder community and the RIPE NCC is happy with, walk it through an open consensus process, and then nobody can argue that the RIPE NCC is going out and bullying/blackmailing ERX holders over their addresses...
(As far as I understand the system, the ERX space would still not be part of the "normal" APWG policy regime - like "RIPE *address* policies have no influence on how the addresses are distributed by the holder's organizationo to 3rd parties" and "no audits", etc.)
Gert Doering -- NetMaster -- 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 (89) 32356-444 USt-IdNr.: DE813185279
Hi,
On Wed, Aug 29, 2012 at 11:08:27AM +0100, Nigel Titley wrote:
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space?
I don't think so.
APWG policy governs under which rules the RIPE NCC gives out (and possible takes back from) internet numbers from the RIPE NCC "pool" to "consumers" - and this sort of obviously only applies to numbers that the RIPE NCC has been given authority over, via the IETF->IANA->RIPE NCC chain of delegation. Good.... and presumably the legacy holders could voluntarily agree to submit to address policy, although it would seem that section 6.3 of the
Gert, As usual you've done your excellent analysis and statement On 29/08/2012 11:21, Gert Doering wrote: proposed policy limits the actions of legacy holders in this respect and indeed it attempts to place bounds on the authority of the community itself for all time (which always gives me pause for thought).
I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all? Now, the RIPE NCC provides services to legacy address space holders that happen to be in the RIPE service region:
- RIPE database and routing registry "who 'owns' it and who is authorized to announce it?" - reverse DNS delegation - potentially: RPKI certificates
due to the way RPSL-authentication and DNS tree'ing work, this is not easy to do in a non-hierarchical structure, so "having this done by the RIPE NCC" makes sense from a technical point of view.
OTOH, I can see that the NCC wants to see some money in exchange for the expenses running all this (and that seems to make sense as well :-) ).
Yes, and bear in mind ultimately the RIPE NCC membership should be consulted about this. It's their money providing the service.
Now, the policy proposal raised here is not an *address space* policy proposal, but an *ncc service* policy proposal - which governs the way the NCC runs their, uh, services. And I think this is a reasonable approach - find something that the ERX holder community and the RIPE NCC is happy with, walk it through an open consensus process, and then nobody can argue that the RIPE NCC is going out and bullying/blackmailing ERX holders over their addresses...
I agree completely with this. This is obvious the best approach, but I still have some reservations about the wording of the proposal as so far seen. Perhaps when it is formally published we could discuss this.
(As far as I understand the system, the ERX space would still not be part of the "normal" APWG policy regime - like "RIPE *address* policies have no influence on how the addresses are distributed by the holder's organizationo to 3rd parties" and "no audits", etc.)
Yes, and this proposal explicitly says that this will be the case for all time. Nigel
At 12:43 29/08/2012 +0100, Nigel Titley wrote:
due to the way RPSL-authentication and DNS tree'ing work, this is not easy to do in a non-hierarchical structure, so "having this done by the RIPE NCC" makes sense from a technical point of view.
OTOH, I can see that the NCC wants to see some money in exchange for the expenses running all this (and that seems to make sense as well :-) ). Yes, and bear in mind ultimately the RIPE NCC membership should be consulted about this. It's their money providing the service.
As a long standing paying member of RIPE NCC, IUCC is willing to pay an additional amount above its current payment level in order to include its legacy blocks under its LIR. It is just open to debate what that level of payment should be. -Hank
Gert, On Wednesday, 2012-08-29 12:21:35 +0200, Gert Doering <gert@space.net> wrote:
due to the way RPSL-authentication and DNS tree'ing work, this is not easy to do in a non-hierarchical structure, so "having this done by the RIPE NCC" makes sense from a technical point of view.
While it is true that DNS is hierarchical, there is no particular reason that the RIPE NCC or any RIR has to be the one managing the reverse DNS.
OTOH, I can see that the NCC wants to see some money in exchange for the expenses running all this (and that seems to make sense as well :-) ).
If it's too costly, I assure you that there are several DNS companies that would be happy to take over the task. -- Shane
Hi, On Wed, Sep 05, 2012 at 01:19:19PM +0200, Shane Kerr wrote:
On Wednesday, 2012-08-29 12:21:35 +0200, Gert Doering <gert@space.net> wrote:
due to the way RPSL-authentication and DNS tree'ing work, this is not easy to do in a non-hierarchical structure, so "having this done by the RIPE NCC" makes sense from a technical point of view.
While it is true that DNS is hierarchical, there is no particular reason that the RIPE NCC or any RIR has to be the one managing the reverse DNS.
True. One the things that speaks in favour of having the RIR do so is "they have the authentication machinery in place". Someone else tasked to run reverse DNS for 194/8 would have to basically copy the RIPE database to be able to judge who is permitted to make changes to "their" DNS delegations ("their" being defined by *RIR* delegation data)... Not that it can't be done, but I don't see any benefit in doing so, unless the service provided by the RIRs degrades to the point where someone else can do better for less cost.
OTOH, I can see that the NCC wants to see some money in exchange for the expenses running all this (and that seems to make sense as well :-) ).
If it's too costly, I assure you that there are several DNS companies that would be happy to take over the task.
So, how would you authenticate that I'm authorized or not to have a DNS delegation for 30.195.in-addr.arpa? Without help of the RIPE NCC? "Being able to run a DNS server" is not the difficult part here (though that seems to be surprisingly difficult in itself, occasionally). Gert Doering -- NetMaster -- 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 (89) 32356-444 USt-IdNr.: DE813185279
Gert, On Wednesday, 2012-09-05 15:56:01 +0200, Gert Doering <gert@space.net> wrote:
If it's too costly, I assure you that there are several DNS companies that would be happy to take over the task.
So, how would you authenticate that I'm authorized or not to have a DNS delegation for 30.195.in-addr.arpa? Without help of the RIPE NCC?
People seem to be able to manage this on the routing side today, so presumably those mechanisms would work here too. But of course it would be even better to have explicit authorization mechanisms. Perhaps the RIRs could develop some sort of address certification technology... ;) I'm not seriously proposing separating DNS management from the RIPE NCC, merely pointing out that all because things have always been done that way doesn't mean that the necessarily have to be done that way. -- Shane
Hi, On Wed, Sep 05, 2012 at 04:53:41PM +0200, Shane Kerr wrote:
On Wednesday, 2012-09-05 15:56:01 +0200, Gert Doering <gert@space.net> wrote:
If it's too costly, I assure you that there are several DNS companies that would be happy to take over the task.
So, how would you authenticate that I'm authorized or not to have a DNS delegation for 30.195.in-addr.arpa? Without help of the RIPE NCC?
People seem to be able to manage this on the routing side today, so presumably those mechanisms would work here too.
Do they? What I've seen here that *works* is "query the RIPE DB for the published route(6): objects for a given AS number, and accept that". What I've seen that does *not* work is "believe if the customer tells you that they own a given network" - one /24 out of my address space was announced by a foreign AS, and their upstream *opened up* their filters to permit it, because the customer called and yelled at them... I'm not aware of any IRRDB *that is properly authenticated* that is not run along the RIR hierarchy - RADB is nice, but since anyone can register anything there, it's worthless for actual verification against purposeful misdoings (or sufficiently advanced fat fingers). RPKI is another option - using RIR hierarchy.
But of course it would be even better to have explicit authorization mechanisms. Perhaps the RIRs could develop some sort of address certification technology... ;)
That could be done, yes. Using the PKI tech for "DNSOA" certification - but that smells like much more effort than to just run the DNS servers :-)
I'm not seriously proposing separating DNS management from the RIPE NCC, merely pointing out that all because things have always been done that way doesn't mean that the necessarily have to be done that way.
I agree with you - but still it's enormously comfortable to use the existing knowledge about address space ownership :-) Gert Doering -- NetMaster -- 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 (89) 32356-444 USt-IdNr.: DE813185279
Gert, On Wednesday, 2012-09-05 22:01:45 +0200, Gert Doering <gert@space.net> wrote:
Hi,
On Wed, Sep 05, 2012 at 04:53:41PM +0200, Shane Kerr wrote:
On Wednesday, 2012-09-05 15:56:01 +0200, Gert Doering <gert@space.net> wrote:
So, how would you authenticate that I'm authorized or not to have a DNS delegation for 30.195.in-addr.arpa? Without help of the RIPE NCC?
People seem to be able to manage this on the routing side today, so presumably those mechanisms would work here too.
Do they?
What I've seen here that *works* is "query the RIPE DB for the published route(6): objects for a given AS number, and accept that".
Yes, this. :) For the DNS side, it could be something as simple as saying "add the comment $RANDOM_TOKEN as a comment to your DOMAIN object". Or even better, using the PGP or X.509 of the address maintainer to authenticate the request.
But of course it would be even better to have explicit authorization mechanisms. Perhaps the RIRs could develop some sort of address certification technology... ;)
That could be done, yes. Using the PKI tech for "DNSOA" certification - but that smells like much more effort than to just run the DNS servers :-)
The initial authentication - and presumably periodic checks - should come from the RIR. There are a few real benefits that could result from a dedicated DNS service though. The biggest benefit would likely be from a service that was not simply a delegation-only service, but also acted as a DNS hoster, either as the primary or secondary source. Of course you can arrange that on your own today, but one-stop-shopping has some value. Also, a service could work across multiple RIRs, so you could manage your worldwide reverse DNS from a single place. (I admit this is not such a big deal, since there are only a few RIRs and any organization spread across multiple regions won't have a huge problem tracking these details.) In order to work across multiple RIRs, it might need to look a bit like a DNS registrar, rather than a registry, since you may not want a single organization controlling the entire reverse DNS. Again, this isn't a serious proposal. It's less serious than when I propose eliminating reverse DNS altogether, at least. :) -- Shane
OTOH, I can see that the NCC wants to see some money in exchange for the expenses running all this (and that seems to make sense as well :-) ). If it's too costly, I assure you that there are several DNS companies that would be happy to take over the task.
for the nonce, let's assume we are a community trying to come together over an old process gap. let's take the high ground on this one. randy
On Wed, 29 Aug 2012, Nigel Titley wrote:
On 29/08/2012 10:18, Jim Reid wrote:
On 29 Aug 2012, at 10:05, Gert Doering wrote:
ERX space has not been given out under RIPE policies, so they do not apply. Period. There is no law, legal contract, or anything else that would make RIPE policies automagically apply to ERX space
+1000.
It's a great pity the recent policy proposal doesn't use those very words.
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space?
Hello, I don't think so. Don't you think some court actions would immediately follow...?
I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all?
"services to" seems to be the key part... :-) Regards, Carlos Friaças
Nigel
On 29 Aug 2012, at 11:08, Nigel Titley wrote:
Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space?
One of the features of our slice of the Internet governance circus is anyone can propose anything. So of course such a policy can be proposed. It might even emerge unscathed from the PDP some time before the heat death of the universe. However that policy would almost certainly face challenges in the courts and lose.
And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all?
I think this is an example of getting your retaliation in first. :-) If the legacy holders can shove something about ERX space through the policy-making machinery, it may well prevent others from filling that vacuum with a more unpleasant policy.
One of the features of our slice of the Internet governance circus is anyone can propose anything.
thank you dr manning
On 29/08/2012 11:08, Nigel Titley wrote:
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space? I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all?
RIPE policies do not apply to ERX address space - there is no real argument about this. However, we have an immediate operational problem caused by the fact that the RIPE NCC has withdrawn the ability for ERX holders to make updates to their address blocks. We got here because some people decided to pass the can from ddn / internic / arin to the RIPE NCC due to geographical considerations. Now that the RIPE NCC has been landed with this mess, they felt that there is a requirement to do something about it rather than let it sit there and fester due to hijacking / illegal transfers. I can see a lot of operational and legal reasons that the NCC blocked updates to the space, even though they were given no direct mandate to do this from the RIPE community. So the issue is really a question of balancing the rights and responsibilities of both the RIPE NCC and the ERX holders. This is why I asked last week if there was an agreement in place between the InterNIC and the RIPE NCC for handling the ERX transfers - if there was a formal agreement in place, then it needs to be given serious consideration when the RIPE community forms a new policy for the RIPE NCC which can be applied to the address space, because the terms of that agreement may still be binding on the RIPE NCC. If there was no agreement in place, then more options are open. Basing a policy on "annexing legacy space" is a red herring. Tut, tut, naughty Nigel. What isn't a red herring is the notion of creating a policy which accepts and understands the requirement of a quid pro quo between the ERX holders and the RIPE NCC. This principal is notably absent in the pre-publication proposal that Niall emailed to the list a couple of days ago, and without prejudice to that document, it is a principal which I suspect would radically change the conclusions of any such proposal. Nick
On 29/08/2012 12:09, Nick Hilliard wrote:
On 29/08/2012 11:08, Nigel Titley wrote:
This actually raises an interesting issue. Are there any circumstances in which RIPE policy would apply to legacy space? Could, for example, the AP-WG unilaterally propose a policy that annexed legacy space? I've heard this suggested several times. And of course, if RIPE policy doesn't apply to legacy space, why are the legacy holders raising a proposal at all? RIPE policies do not apply to ERX address space - there is no real argument about this.
However, we have an immediate operational problem caused by the fact that the RIPE NCC has withdrawn the ability for ERX holders to make updates to their address blocks. We got here because some people decided to pass the can from ddn / internic / arin to the RIPE NCC due to geographical considerations. Now that the RIPE NCC has been landed with this mess, they felt that there is a requirement to do something about it rather than let it sit there and fester due to hijacking / illegal transfers. I can see a lot of operational and legal reasons that the NCC blocked updates to the space, even though they were given no direct mandate to do this from the RIPE community. Can we get this straight please. The RIPE NCC has *not* withdrawn ability for ERX holders to make updates to their address block, neither has it withdrawn reverse DNS service. Letters to that effect were sent to a number of legacy holders but were issued in error due to a miscommunication within the RIPE NCC and were withdrawn. If anyone still has no access to their database records then this is an operational error and it should be reported through the usual channels.
We now have the opportunity to get this whole thing straightened out, with a proper mandate from the community. That is what this whole proposal is about.
So the issue is really a question of balancing the rights and responsibilities of both the RIPE NCC and the ERX holders. This is why I asked last week if there was an agreement in place between the InterNIC and the RIPE NCC for handling the ERX transfers - if there was a formal agreement in place, then it needs to be given serious consideration when the RIPE community forms a new policy for the RIPE NCC which can be applied to the address space, because the terms of that agreement may still be binding on the RIPE NCC. If there was no agreement in place, then more options are open.
I'll be surprised if there was no agreement. Can someone from the RIPE NCC comment?
Basing a policy on "annexing legacy space" is a red herring. Tut, tut, naughty Nigel.
As I said that was a little mischievious, but it has led to considerable clarification of what is being done here.
What isn't a red herring is the notion of creating a policy which accepts and understands the requirement of a quid pro quo between the ERX holders and the RIPE NCC. This principal is notably absent in the pre-publication proposal that Niall emailed to the list a couple of days ago, and without prejudice to that document, it is a principal which I suspect would radically change the conclusions of any such proposal.
I agree fully with this and I hope that this clarification will emerge during the discussion phase of the proposal. Nigel
On 29/08/2012 12:19, Nigel Titley wrote:
Can we get this straight please. The RIPE NCC has *not* withdrawn ability for ERX holders to make updates to their address block, neither has it withdrawn reverse DNS service. Letters to that effect were sent to a number of legacy holders but were issued in error due to a miscommunication within the RIPE NCC and were withdrawn. If anyone still has no access to their database records then this is an operational error and it should be reported through the usual channels.
ah, good. I was not aware that this was the situation. Nick
On 29 Aug 2012, at 12:19, Nigel Titley wrote:
We now have the opportunity to get this whole thing straightened out, with a proper mandate from the community. That is what this whole proposal is about.
Absolutely! /Niall
On 29.08.2012, at 13:19 , Nigel Titley wrote:
On 29/08/2012 12:09, Nick Hilliard wrote: So the issue is really a question of balancing the rights and responsibilities of both the RIPE NCC and the ERX holders. This is why I asked last week if there was an agreement in place between the InterNIC and the RIPE NCC for handling the ERX transfers - if there was a formal agreement in place, then it needs to be given serious consideration when the RIPE community forms a new policy for the RIPE NCC which can be applied to the address space, because the terms of that agreement may still be binding on the RIPE NCC. If there was no agreement in place, then more options are open. I'll be surprised if there was no agreement. Can someone from the RIPE NCC comment?
Comment from someone involved at the time who happens to work at the RIPE NCC: ERX was an activity of the RIRs undertaken upon request from their communities. It was structured by informal agreements which were adapted in the light of experience and governed by the respective RIR governance processes. No higher authority authorised ERX. IANA was informed and welcomed the effort to increase the quality if the Internet Number Registry. I do not consider this a relevant question at all. The InterNIC does not exist anymore and it is questionable if it ever existed in a legal sense. To a lesser extent this goes for IANA as well, but there is general acceptance of the authority of the IANA. The RIPE community can freely decide policies for registrations in the RIPE Internet Number Registry. There are a small number of boundary conditions, such as good faith towards address space users and the laws of the Netherlands. Previous agreements about address space distribution to which the RIPE NCC was not a party are not part of them. See also my longish contribution of a few minutes ago Daniel
On 29/08/2012 16:16, Daniel Karrenberg wrote:
On 29.08.2012, at 13:19 , Nigel Titley wrote:
On 29/08/2012 12:09, Nick Hilliard wrote: So the issue is really a question of balancing the rights and responsibilities of both the RIPE NCC and the ERX holders. This is why I asked last week if there was an agreement in place between the InterNIC and the RIPE NCC for handling the ERX transfers - if there was a formal agreement in place, then it needs to be given serious consideration when the RIPE community forms a new policy for the RIPE NCC which can be applied to the address space, because the terms of that agreement may still be binding on the RIPE NCC. If there was no agreement in place, then more options are open. I'll be surprised if there was no agreement. Can someone from the RIPE NCC comment? Comment from someone involved at the time who happens to work at the RIPE NCC:
ERX was an activity of the RIRs undertaken upon request from their communities. It was structured by informal agreements which were adapted in the light of experience and governed by the respective RIR governance processes. No higher authority authorised ERX. IANA was informed and welcomed the effort to increase the quality if the Internet Number Registry.
I do not consider this a relevant question at all. The InterNIC does not exist anymore and it is questionable if it ever existed in a legal sense. To a lesser extent this goes for IANA as well, but there is general acceptance of the authority of the IANA. It is relevant because the proposal before this working group makes repeated reference to it. It probably shouldn't, and in any case having spoken to Axel (now confirmed by you) no such formal agreement exists. So this is relevant, but null.
The RIPE community can freely decide policies for registrations in the RIPE Internet Number Registry. There are a small number of boundary conditions, such as good faith towards address space users and the laws of the Netherlands. Previous agreements about address space distribution to which the RIPE NCC was not a party are not part of them.
See also my longish contribution of a few minutes ago
Noted. Nigel
On 29 Aug 2012, at 11:08, Nigel Titley wrote:
Are there any circumstances in which RIPE policy would apply to legacy space?
I guess there could be, but we don't have them yet. I expect that achieving such circumstances will require us all to give more than usual care to how we understand "consensus" and "fairness". For avoidance of doubt, I'm not claiming to have done this yet. 8-) /Niall
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.08.2012 11:05, Gert Doering wrote:
Hi,
On Wed, Aug 29, 2012 at 03:06:08AM +0200, Michael Markstaller wrote:
Just my 2ct: not any University or worse religous campaign should block a /8 or /16 without having to state HERE&NOW why and for what they really need&use it. They need exactly 1 IP for every 65536 concurrently active student to NAT and 1 for each public service at most, lets put a /22 for infra on top and then we're fine..
This is not how the old Internet used to work, and it is not how it works today - nobody is forced to use NAT by the RIRs, and that's how it must be (*and* it has nothing to do with the question of ERX space governance whatsoever).
Ok, this was a intentionally a little provocative. I - admittetly - don't know much about the internals and policys/proposals of InterNIC or RIPE NCC and what this WG is really about. And learned much today from the various posts.
We have to do either I guess, at least we do, according to RIPE-policys. So we're playing with different cards here, legacy holders are being asked "what might be a nice proposal they like", I'm not asked what "might be nice for me"
ERX space has not been given out under RIPE policies, so they do not apply. Period. There is no law, legal contract, or anything else that would make RIPE policies automagically apply to ERX space (and even *then*, there would not be any RIPE policy forcing a user of IP address space to use NAT if they do not want to).
It would solve nothing. If people insist on cementing their IPv4 world for a few more years, they would have *more* stuff to move to IPv6 in the long run - nothing solved. Agreed, not solve but shift the "problem" - though, I'm no enemy of v6, just to tell you my real-world view of IPv6: No single customer was ever interested in, no single hit on the servers we ran a while back around v6-Day, no single user on the xDSL we provide wanted to use it; the only result were new problems nobody pays for. Don't take this as a rant please, I know about your efforts in many ways, the problems are sourced by low usage/training etc. But it's a real big chicken-egg-problem and as a very small provider in business my primary job is to get a working infrastructure and happy customers
Well I remember ther (was?) or is some policy or draft suggesting this at least for 2G/3G networks which not all providers do and, well which is IMHO nonsense in context of IPv4 really running out to give each Gadget in my pocket a public IP.. that pay money; none of them ever wanted to pay a single Euro for v6 (maybe because you have all of them ;)) On 29.08.2012 12:21, Gert Doering wrote:
Now, the policy proposal raised here is not an *address space* policy proposal, but an *ncc service* policy proposal - which governs the way the NCC runs their, uh, services. And I think this is a reasonable approach - find something that the ERX holder community and the RIPE NCC is happy with, walk it through an open consensus process, and then nobody can argue that the RIPE NCC is going out and
bullying/blackmailing
ERX holders over their addresses...
Thats a key point, I didnt really get so far.. On 29.08.2012 21:58, Carsten Schiefner wrote:> Hi Nick,
On 29.08.2012 19:33, Nick Hilliard wrote:
On 29/08/2012 17:09, Hank Nussbacher wrote:
in addition to ideas stated here to take away our legacy IP allocations and give us /22s and force us to use NAT and reengineer our 10,000 node university networks
No idea where this idea came from. No-one has ever suggested this or even remotely implied it. Quite the opposite in fact.
may I suggest you re-read Michael Markstaller's posting of Wed, 29 Aug 2012 03:06:08 +0200? It's archived at:
https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.h... It was me, yes, and sorry for the rant. It wasn't based on any known policy or proposal but just on my Opinion and then 2ct.. Since I know now, again the proposal discussed (quoted again) is not an *address space* policy proposal, but an *ncc service* policy proposal. Ok.. But then I have another 2ct if this is relevant under this topic: I found no details in the proposals how the deal with "selling v4 addresses"(*) which will IMHO happen soon when v4 is fully exhausted. *I don't vote for this* but one or another way, it might be "cheaper" to "buy" v4 space then migrate networks, so it will happen. If I get with limited knowledge things right now, this might be a topic that could be of relevance in future. *) This was discussed quite a while back, maybe on another WG for a short time but AFAIR didn't make it to a conclusion. best regards Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlA+f8MACgkQaWRHV2kMuAKuKwCfR1xibpJJvd6UugoehCbRLy+9 6zIAn0PMuVXgYWM0uLN4CnzCK5eaxq0L =xMKo -----END PGP SIGNATURE-----
Hello, On Wed, 29 Aug 2012, Michael Markstaller wrote:
It would solve nothing. If people insist on cementing their IPv4 world for a few more years, they would have *more* stuff to move to IPv6 in the long run - nothing solved. Agreed, not solve but shift the "problem" - though, I'm no enemy of v6, just to tell you my real-world view of IPv6: No single customer was ever interested in, no single hit on the servers we ran a while back around v6-Day, no single user on the xDSL we provide wanted to use it; the only result were new problems nobody pays for.
Maybe you missed some previous messages, or the messages were not clear enough: the lack of address space is not a user problem, it's a service provider's problem. However, the service provider can make this a user's problem if they choose to NAT, double-NAT, triple-NAT, ... ;-(
Don't take this as a rant please, I know about your efforts in many ways, the problems are sourced by low usage/training etc.
We still see situations were there was a clear gap in IPv4 training too... ;-)
But it's a real big chicken-egg-problem and as a very small provider in business my primary job is to get a working infrastructure and happy customers that pay money; none of them ever wanted to pay a single Euro for v6 (maybe because you have all of them ;))
And customers also don't want to pay for 32-bit numbers. All they want is "service", their applications to work, and so forth...
But then I have another 2ct if this is relevant under this topic: I found no details in the proposals how the deal with "selling v4 addresses"(*) which will IMHO happen soon when v4 is fully exhausted. *I don't vote for this* but one or another way, it might be "cheaper" to "buy" v4 space then migrate networks, so it will happen. If I get with limited knowledge things right now, this might be a topic that could be of relevance in future.
*) This was discussed quite a while back, maybe on another WG for a short time but AFAIR didn't make it to a conclusion.
The policy proposal, afaik, will be improved during the discussion phase. Selling *legacy* v4 addresses is something that i think it already happenned in other regions, but anyway i don't think that is this policy's focus... ps: "cheaper" always depends on the timeframe you're considering. It may be cheaper in the short-run (3m, 6m, 1y, ...), but that option can in fact turn out to be more expensive if you cannot scale it, and you finally understand you need to go through an emergency migration process, and possibly lose customers or potential customers during that phase. :-) Best Regards, Carlos Friaças
best regards
Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlA+f8MACgkQaWRHV2kMuAKuKwCfR1xibpJJvd6UugoehCbRLy+9 6zIAn0PMuVXgYWM0uLN4CnzCK5eaxq0L =xMKo -----END PGP SIGNATURE-----
Hank, On 29/08/2012 01:07, Hank Nussbacher wrote:
At 23:20 28/08/2012 +0100, Nick Hilliard wrote:
then does IUCC maintain some sort of beneficial claim of registration over subnets of the blocks you list - the sort of claim that would entitle you to say that because this was IUCC space rather than IUCC member space, that it really ought to be covered under IUCC's LIR membership for any future potential argument about a RIPE ERX policy?
Only IP space that remains maintained under our LIR/NREN (il.iucc).
It is not maintained under il.iucc, because il.iucc is a legal construct which exists between the RIPE NCC and IUCC. The only address space managed by il.iucc is 2001:0bf8::/32. Any other address space handled by IUCC have is either ERX or outside the scope of the RIPE NCC. [...]
My answer would be "Whatever is decided upon by the RIPE membership and not unilaterally by RIPE NCC management". But your initial comment of "On the one hand, ERX holders obtained address space without a governing contract and have been enjoying the benefits of this for many years. On the other hand, someone is footing the bill for the maintenance and upkeep of this registration data - namely the RIPE NCC membership." is clearly wrong in many cases since il.iucc has been "footing the bill" for all ERX space listed under its LIR.
Not really, no. The entry in alloclist.txt for il.iucc is:
il.iucc IUCC - Israel InterUniversity Computation Center
20030508 2001:0bf8::/32
There's no mention of any ipv4 address space, and il.iucc is categorised as "extra small". I cannot see how this means that il.iucc is footing the bill for maintenance of the registry entries any more than every other RIPE NCC member is.
And if there is a precedent for tacitly agreeing that e.g. commercial / governmental ERX assignees are not subject to any NRENs' beneficial claims over the address space for whatever reason, then on what basis are you claiming that the NRENs have any beneficial claim over their members' address space?
Because in our case, the members (read universities), are the "owners" of the NREN. Legally speaking.
I understand the distinction - I've been working with member-owned organisations for a long time. However legally speaking, the assets of a member-owned organisation are owned by that organisation, not by the members. The organisation as a whole belongs to the members. Do I have a right to take Axel Pawlik's laptop? He works for the RIPE NCC, and ie.netability is a member of the RIPE NCC, and I own ie.netability. Based on your assertion, I might have some sort of claim to taking it, but the legal reality is that I have no claim whatsoever. Let me put it another way: what would happen if a member were to leave your NREN? Does IUCC stake its claim on the addresses at that point or not? And if not, then on what basis do you stake any claim on the IP address space now? And as a secondary issue (to ownership, but not to the point you were originally making), if you are not staking a claim on beneficial interest in the address space now, then why are you claiming that they should just be bundled in as something similar to ALLOCATED PA address space from the point of view of your LIR membership in any future agreement with the RIPE NCC - except that you're also claiming in the policy document that it shouldn't be counted towards a LIR allocation, but should be charged as strictly less than a PI assignment per block. Hank, I'm not trying to be confrontational here. There's an important issue which I'm trying to get to the bottom of, namely the issue of where the rights and responsibilities lie between the address assignees and their historical registrars. So far I've seen nothing to suggest that the registrars have any sort of reasonable claim to the address space other; nor have I seen any indication that the assignees have given informed consent to these claims. These are important issues because they are pretty much guaranteed to become problems in situations of changes of circumstance (potentially such as this one). Nick
At 11:14 29/08/2012 +0100, Nick Hilliard wrote:
Hank,
At 23:20 28/08/2012 +0100, Nick Hilliard wrote:
then does IUCC maintain some sort of beneficial claim of registration over subnets of the blocks you list - the sort of claim that would entitle you to say that because this was IUCC space rather than IUCC member space,
On 29/08/2012 01:07, Hank Nussbacher wrote: that
it really ought to be covered under IUCC's LIR membership for any future potential argument about a RIPE ERX policy?
Only IP space that remains maintained under our LIR/NREN (il.iucc).
It is not maintained under il.iucc, because il.iucc is a legal construct which exists between the RIPE NCC and IUCC. The only address space managed by il.iucc is 2001:0bf8::/32. Any other address space handled by IUCC have is either ERX or outside the scope of the RIPE NCC.
[...]
My answer would be "Whatever is decided upon by the RIPE membership and not unilaterally by RIPE NCC management". But your initial comment of "On the one hand, ERX holders obtained address space without a governing contract and have been enjoying the benefits of this for many years. On the other hand, someone is footing the bill for the maintenance and upkeep of this registration data - namely the RIPE NCC membership." is clearly wrong in many cases since il.iucc has been "footing the bill" for all ERX space listed under its LIR.
Not really, no. The entry in alloclist.txt for il.iucc is:
il.iucc IUCC - Israel InterUniversity Computation Center
20030508 2001:0bf8::/32
There's no mention of any ipv4 address space, and il.iucc is categorised as "extra small". I cannot see how this means that il.iucc is footing the bill for maintenance of the registry entries any more than every other RIPE NCC member is.
And if there is a precedent for tacitly agreeing that e.g. commercial / governmental ERX assignees are not subject to any NRENs' beneficial claims over the address space for whatever reason, then on what basis are you claiming that the NRENs have any beneficial claim over their members' address space?
Because in our case, the members (read universities), are the "owners" of the NREN. Legally speaking.
I understand the distinction - I've been working with member-owned organisations for a long time. However legally speaking, the assets of a member-owned organisation are owned by that organisation, not by the members. The organisation as a whole belongs to the members.
Do I have a right to take Axel Pawlik's laptop? He works for the RIPE NCC, and ie.netability is a member of the RIPE NCC, and I own ie.netability. Based on your assertion, I might have some sort of claim to taking it, but the legal reality is that I have no claim whatsoever.
Let me put it another way: what would happen if a member were to leave your NREN? Does IUCC stake its claim on the addresses at that point or not? And if not, then on what basis do you stake any claim on the IP address space now? And as a secondary issue (to ownership, but not to the point you were originally making), if you are not staking a claim on beneficial interest in the address space now, then why are you claiming that they should just be bundled in as something similar to ALLOCATED PA address space from the point of view of your LIR membership in any future agreement with the RIPE NCC - except that you're also claiming in the policy document that it shouldn't be counted towards a LIR allocation, but should be charged as strictly less than a PI assignment per block.
Hank, I'm not trying to be confrontational here.
Nick, As much as it would appear fun and amusing to make il.iucc into a punching bag for RIPE NCC legacy policy, in addition to ideas stated here to take away our legacy IP allocations and give us /22s and force us to use NAT and reengineer our 10,000 node university networks, I think I will stop posting here and await to see what general policy is accepted by RIPE NCC for legacy IP space. -Hank
There's an important issue which I'm trying to get to the bottom of, namely the issue of where the rights and responsibilities lie between the address assignees and their historical registrars. So far I've seen nothing to suggest that the registrars have any sort of reasonable claim to the address space other; nor have I seen any indication that the assignees have given informed consent to these claims.
These are important issues because they are pretty much guaranteed to become problems in situations of changes of circumstance (potentially such as this one).
Nick
On 29.08.2012, at 18:09 , Hank Nussbacher wrote:
As much as it would appear fun and amusing to make il.iucc into a punching bag for RIPE NCC legacy policy, in addition to ideas stated here to take away our legacy IP allocations and give us /22s and force us to use NAT and reengineer our 10,000 node university networks, I think I will stop posting here and await to see what general policy is accepted by RIPE NCC for legacy IP space.
Hey Hank, you are a better sport than that! Good policy comes only by discussion. And despite some e-mail induced friction we all do respect each other. Please stay in the discussion. Especially if it focuses on the registration policy, as it should. Daniel And just as a reminder for those folks younger than Hank and myself, let me quote from the second RIPE NCC Quarterly Report (ripe-73): "Funding for the first year of operation of the NCC is provided by EARN, the national members of RARE, Israel and EUnet." The reason Israel is mentioned here, is that Israel's NREN at the time was not a formal member of RARE; some argument about Israel not being in "Europe"; a problem RIPE never had. If I recall correctly Hank was very active in EARN at the time and certainly also contributed to the Israeli NREN. So one could say that Hank was active in the first funders of the RIPE NCC 20 years ago.
On 29/08/2012 17:09, Hank Nussbacher wrote:
As much as it would appear fun and amusing to make il.iucc into a punching bag for RIPE NCC legacy policy
Hank, I'm surprised and saddened that you think that I intended to poke fun at IUCC or turn it into a punching bag. This was genuinely not my intention and I think I made this clear in previous emails: "I'm not fishing for answers to these specific questions, btw. I'm interested in the general issue"... and: "I'm not trying to be confrontational here. There's an important issue which I'm trying to get to the bottom of, namely the issue of where the rights and responsibilities lie between the address assignees and their historical registrars." If I've offended you or cause offence to IUCC or its members by using your good name as an example, please accept my sincere and unconditional apologies. My intention was solely to discover, not to offend.
in addition to ideas stated here to take away our legacy IP allocations and give us /22s and force us to use NAT and reengineer our 10,000 node university networks
No idea where this idea came from. No-one has ever suggested this or even remotely implied it. Quite the opposite in fact.
I think I will stop posting here and await to see what general policy is accepted by RIPE NCC for legacy IP space.
Please don't. Your contributions are valuable. Nick
Hi Nick, On 29.08.2012 19:33, Nick Hilliard wrote:
On 29/08/2012 17:09, Hank Nussbacher wrote:
in addition to ideas stated here to take away our legacy IP allocations and give us /22s and force us to use NAT and reengineer our 10,000 node university networks
No idea where this idea came from. No-one has ever suggested this or even remotely implied it. Quite the opposite in fact.
may I suggest you re-read Michael Markstaller's posting of Wed, 29 Aug 2012 03:06:08 +0200? It's archived at: https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.h... Best, Carsten
On 29/08/2012 20:58, Carsten Schiefner wrote:
may I suggest you re-read Michael Markstaller's posting of Wed, 29 Aug 2012 03:06:08 +0200? It's archived at:
https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.h...
Someone else kindly pointed this out already - I didn't actually notice this. I'm not sure which particular RIPE policy Michael Markstaller was referring to when he suggested enforced withdrawal of address assignments in his email, but it's not one I'm familiar with. Nick
On 29.08.2012, at 21:58 , Carsten Schiefner wrote:
Hi Nick,
On 29.08.2012 19:33, Nick Hilliard wrote:
On 29/08/2012 17:09, Hank Nussbacher wrote:
in addition to ideas stated here to take away our legacy IP allocations and give us /22s and force us to use NAT and reengineer our 10,000 node university networks
No idea where this idea came from. No-one has ever suggested this or even remotely implied it. Quite the opposite in fact.
may I suggest you re-read Michael Markstaller's posting of Wed, 29 Aug 2012 03:06:08 +0200? It's archived at:
https://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.h...
[Personal title disclaimer as usual] I read that too and felt reminded of similar proposals over the years. None of these have made it past initial discussion in the community for a fair number of reasons. The discussions are archived and available to everyone. Of course there is a danger that such proposals may gain more traction now that nobody can ignore any longer that we will reach the final /8 soon. However I am optimistic and I do believe that our community is more mature than to fall for that or into that trap. We will experience all sorts of ugly things for a period, but this is not one of them. Daniel who had pledged not to engage in addresspolicy discussions anymore, but this is "services", right? ;-) At least I will call it a day for now.
On 29.08.2012 22:28, Daniel Karrenberg wrote:
[...] At least I will call it a day for now.
We all should. At least those in and adjacent to CEST. :-) Best, -C.
in addition to ideas stated here to take away our legacy IP allocations and give us /22s and force us to use NAT and reengineer our 10,000 node university networks
No idea where this idea came from. No-one has ever suggested this or even remotely implied it. Quite the opposite in fact.
Uh... I think this came from Message-ID: <503D6B00.7000605@elabnet.de>, from Michael Markstaller earlier in this thread, ref. http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2012-August/001738.ht... Just for the record: I consider his suggestion to be totally outlandish, just the notion that "all one needs at any one time as a user is a single NAT'ed socket" is so far out of touch with what consitutes "need" that the rest isn't really worthy of comments. However, just for the record, let me say this: the community really should accept that historical assignments should not be put into question, at least not as part of this discussion, also not at the present time, and it is somewhat doubtful that they ever can be. The only realistic and straight-forward way to re-claim legacy IPv4 address space is through voluntary surrender by the current holder. Therefore, I think I agree with what Daniel Karrenberg said about what the present discussion should be about, I'm quoting: So what we have to decide as a community is: under which policies does the RIPE community allow legacy space holders to register their address space in the RIPE Internet Number registry. Nothing more, nothing less. All other questions are secondary. Resolving conflicts about the holdership/use of the address space is a non issue. Past agreements about allocation of address space are a non issue. [...] (I have a question of terminology that I'll bring up in a separate message.) Best regards, - Håvard
On 30 Aug 2012, at 11:00, Havard Eidnes wrote:
Therefore, I think I agree with what Daniel Karrenberg said about what the present discussion should be about, I'm quoting:
So what we have to decide as a community is: under which policies does the RIPE community allow legacy space holders to register their address space in the RIPE Internet Number registry. Nothing more, nothing less.
All other questions are secondary. Resolving conflicts about the holdership/use of the address space is a non issue. Past agreements about allocation of address space are a non issue. [...]
(I have a question of terminology that I'll bring up in a separate message.)
I think I agree too. Background work on a new version of the policy proposal has begun. It is premature for me to say more at this stage. Best regards, Niall
On 30/08/2012 11:00, Havard Eidnes wrote:
Just for the record: I consider his suggestion to be totally outlandish, just the notion that "all one needs at any one time as a user is a single NAT'ed socket" is so far out of touch with what consitutes "need" that the rest isn't really worthy of comments.
That is a polite way of putting it, yes. I agree completely.
However, just for the record, let me say this: the community really should accept that historical assignments should not be put into question
I also agree completely with this.
at least not as part of this discussion, also not at the present time, and it is somewhat doubtful that they ever can be.
The only realistic and straight-forward way to re-claim legacy IPv4 address space is through voluntary surrender by the current holder.
As we're talking about registration in a database, the RIPE NCC has a stewardship responsibility to ensure that the registration details are "correct", for some meaning of the word "correct" which needs to be defined by policy (which is why I was interested in the NREN / NREN member position on the ultimate assignee). As such, the registration policy means that the RIPE NCC will need to perform some level of due process with regard to identifying the ERX holders. This will inevitably lead to the identification of ERX space which is registered to organisations / persons which no longer exist, and in this case there may be a argument to take these addresses out of circulation in order to stop hijacking (whether that means preventing updates or deregistering them/returning them to the IANA pool or something else, I do not know). I would be happy for this not to be part of any initial policy, but I do believe that garbage collection will be a necessary part of the overall ERX management process and that we will eventually need to look at this from a policy point of view. Other than garbage collection, I see no basis for reclaiming v4 address space other than by voluntary return. Nick
On 30 Aug 2012, at 11:00, Havard Eidnes wrote:
Therefore, I think I agree with what Daniel Karrenberg said about what the present discussion should be about, I'm quoting:
So what we have to decide as a community is: under which policies does the RIPE community allow legacy space holders to register their address space in the RIPE Internet Number registry. Nothing more, nothing less.
Indeed. I think it will be helpful to close this thread and start a new one which focuses on this key point. IMO legacy holders should be able to register/manage their space in the NCC database and get the equivalent service they would have enjoyed from SRI or whoever it was that issued the space all those years ago. Since that service was free back then, the comparable services for that space today from the NCC -- updating contact objects and delegation info mostly -- should be free too. YMMV. The incremental cost to the NCC of doing that should be negligible. The database and its supporting infrastructure is already there. And besides, the NCC provides services for the benefit of the broader Internet community than just its members. These must be costing quite a bit more than supporting a bunch of legacy space database entries. So the actual costs of this "free" service to legacy holders would probably be lost in the noise. Of course if that turned out not to be the case, then some mechanism would need to be found to fund it. Says he hand-waving from a distance... A fee of a few euro per update could do that but may be more bother than it's worth. It may well cost more than that to raise an invoice and do the bean counting. If/when the legacy holder needs additional RIR services related to that space -- say a secure reverse delegation or a cert for RPKI -- they can either pay for that on a cost recovery basis or become an LIR. Those services didn't exist when they got the space, so it's only right that a legacy holder pays for that extra functionality somehow.
Hi, earlier I muttered something about terminology in conjunction with what we're actually discussing about the legacy resource holders. Daniel wrote: So what we have to decide as a community is: under which policies does the RIPE community allow legacy space holders to register their address space in the RIPE Internet Number registry. Nothing more, nothing less. Now, first, as far as I've gathered, the RIPE Internet Number registry is *not* the same as the RIPE database. We even have a fine informational document, ripe-508, with the title "The RIPE registry". Is "The RIPE registry" and "the RIPE Internet Number registry" one and the same? Secondly, ripe-508 speaks about the data in "The RIPE registry", and that document also talks about the legacy resources the RIPE NCC has the record-keeping responsibility for, and mentions that this includes Internet number resources which were assigned before the RIPE NCC was (fully) established, and that these resources are already a part of "The RIPE registry", tagged as "legacy". A side question here would be whether a "complete" public view of "The RIPE registry" is available in any manner? The delegated-ripencc- latest file in ftp.ripe.net:/pub/stats/ripencc/ does not list any resources marked "legacy". Unless someone is intentionally playing with words with the intent to confuse, and "the RIPE registry" is separate and different from "The RIPE Internet Number registry" (I doubt that's the case), this makes me a little uncertain about what *exactly* it is we are discussing when it comes to the handling of the legacy resources, because according to ripe-508 the legacy resources used in the RIPE NCC service region should already be registered in "The RIPE registry". Can someone in authority please make an attempt to clear up this particular source of confusion? Best regards, - Håvard
In view of your role as the network coordinator for the universities and governmental departments in Israel, we here at the Network Information Center feel it would be appropriate if you could serve as the IP number delegating authority for the country of Israel.
this was far from universal. but the same did happen in za. eventually it drove the za admin, who was not a control freak, nuts and they dumped it all back on postel and later afrinic. randy
On 19 Jul 2012, at 16:03, Andrew de la Haye wrote:
We regret this mistake and apologise sincerely for the confusion and any distress this might have caused.
[and more: see archive] Better late than never. Among others, I have been trying to draw attention to the problem behind this since Vienna, privately ands publicly, including in sldes I presented at Ljubljana. Something seems to be seriously broken in the NCC's radar. I'm very glad to see what seems to be a change of course at last. I look forward to seeing indications of the appropriate lessons being learned. Best regards Niall PS. "Reply-To: noreply@ripe.net" is inappropriate -- almost always, but especially now. /N
At 16:11 19/07/2012 +0200, Sander Steffann wrote:
So, following the acceptance of 2007-01 by the community: if the RIPE NCC requires legacy holders to sign such a contract (contract with sponsoring LIR) they are doing something which directly contradicts an accepted RIPE policy... If any legacy holder already signed such a contract I strongly feel that they should either be given the option to void the contract, or the contract should be declared void automatically.
- Sander
What shocked me when I got the attached template was how the English was not grammatically correct and how unwilling the NCC was willing to make any change to the template. Just taking section II: II. The LIR made an appropriate control to the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder. I had suggested the more correct form of: II. The LIR has established the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder. but was turned down (as well as the 4 other changes I suggested to sections 2+3). This template was never brought to the membership, but is presented as a "done deal" that every legacy holder has to sign. I call it NCC out of control. -Hank
Hi,
What shocked me when I got the attached template was how the English was not grammatically correct and how unwilling the NCC was willing to make any change to the template.
Just taking section II: II. The LIR made an appropriate control to the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder.
I had suggested the more correct form of: II. The LIR has established the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder.
but was turned down (as well as the 4 other changes I suggested to sections 2+3).
This is a different template than the one from RIPE-452. Are there multiple EndUser<->LIR contract templates in use?
This template was never brought to the membership, but is presented as a "done deal" that every legacy holder has to sign.
Yes, I can't remember any policy proposal that specified these requirements. Where do they come from? Thanks, Sander
At 17:51 19/07/2012 +0200, Sander Steffann wrote:
Hi,
What shocked me when I got the attached template was how the English was not grammatically correct and how unwilling the NCC was willing to make any change to the template.
Just taking section II: II. The LIR made an appropriate control to the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder.
I had suggested the more correct form of: II. The LIR has established the correctness of the information provided by the Legacy Resource Holder and wishes to register the Legacy Resources on their LIR account on behalf of the Legacy Resource Holder.
but was turned down (as well as the 4 other changes I suggested to sections 2+3).
This is a different template than the one from RIPE-452. Are there multiple EndUser<->LIR contract templates in use?
You can download it youself from: http://www.ripe.net/lir-services/resource-management/legacy-space/template-a...
This template was never brought to the membership, but is presented as a "done deal" that every legacy holder has to sign.
Yes, I can't remember any policy proposal that specified these requirements. Where do they come from?
From the RIPE site as listed above. -Hank
Thanks, Sander
participants (23)
-
Andrew de la Haye -
Andrew de la Haye -
Carlos Friacas -
Carsten Schiefner -
Daniel Karrenberg -
Gert Doering -
Hank Nussbacher -
Havard Eidnes -
Jim Reid -
Lindqvist Kurt Erik -
Marcus Stoegbauer -
Martin Stanislav -
Michael Markstaller -
Niall O'Reilly -
Nick Hilliard -
Nigel Titley -
Nigel Titley -
Peter Koch -
Randy Bush -
Rogier Spoor -
Sander Steffann -
Shane Kerr -
Tore Anderson