2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders)
Dear Colleagues, The draft document for the version 3.0 of the proposal described in 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders", has been published. The impact analysis that was conducted for this proposal has also been published. Highlight of the main differences from version 2.0 -rewording of the first paragraph of the Introduction into two new paragraphs -new definition of Legacy Internet Resources -added definition of Registry Service Element -additional text in the Scope section -rewording and new text in sections 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 2.6, 5.0 -removed the reference section 6.0 You can find the full proposal and the impact analysis at: https://www.ripe.net/ripe/policies/proposals/2012-07 and the draft document at: https://www.ripe.net/ripe/policies/proposals/2012-07/draft We encourage you to read the draft document text and send any comments to before 3 June 2013. Regards Emilio Madaio Policy Development Officer RIPE NCC
On 6 May 2013, at 13:19, Emilio Madaio wrote:
You can find the full proposal and the impact analysis at:
https://www.ripe.net/ripe/policies/proposals/2012-07
and the draft document at:
https://www.ripe.net/ripe/policies/proposals/2012-07/draft
We encourage you to read the draft document text and send any comments to before 3 June 2013.
I'm pleased to see the RIPE NCC's Impact Analysis, which seems clear, thorough, cautious, and mostly helpful. I've used the "Executive Summary" section as a framework for my comments, in context below. This approach means that the more detailed text in the Impact Assessment is, for the time being, out of sight for me. Because of this, I may ask for clarification which is already available to me. My comments are made in a personal capacity, without any claim to represent any of the following: my employer, the other co-authors of the proposal, or legacy resource holders.
1. The proposal refers to the terms and conditions under which the Legacy Internet Resources were originally granted. The RIPE NCC will need to be informed as to the content of these original terms and conditions to properly determine their impact.
This need seems to be overstated. Beyond what is necessary to determine whether the party involved is indeed the legitimate holder of the resource in question, what need can the RIPE NCC have for the information mentioned?
2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests.
This is information of which I was not previously aware. I appreciate being made aware of this and intend to ensure that it is taken into account during the proposal's next revision cycle.
3. Due diligence checks will be required to verify the legitimacy of Legacy Resource Holders. If the correct documentation cannot be provided, the RIPE NCC will be unable to enter into a contractual relationship with the Legacy Resource Holder.
To the extent the the diligence applied is indeed "due", and conforms with reality rather than with some conventional concept or recipe, this seems reasonable. Due diligence needs to be informed by both Balance of Probability and Balance of Convenience. It seems to me that a test which the RIPE NCC might reasonably use would be whether sufficient trust exists for a good-faith belief in the legitimacy of the claim to hold the resources in question. I expect that the issue here is whether the RIPE NCC can safely offer registration services (possibly including certification) in each specific case.
4. Section 2.1 of the proposal allows Legacy Internet Resources to be covered by the RIPE NCC Standard Service Agreement (SSA). Modifications to the SSA will require approval by the General Meeting (GM).
The GM has the necessary power. I expect that it will be for a member with some interest in legacy resources to bring forward a proposal that the GM exercise this power.
5. Section 2.4 of the proposal allows the Legacy Resource Holder to engage directly with the RIPE NCC through a special contract if they cannot find a sponsoring LIR. The RIPE NCC cannot think of any circumstances where this might be the case. Also, the creation of such a special class of contract would require approval by the GM.
My remark to point 4 applies also to point 5.
6. Similarly, section 2.5 allows the Legacy Resource Holder to conclude no contact due to special enduring circumstances. The RIPE NCC cannot think of what these circumstances might be, and some Registration Services cannot be performed without a contract in place. Additionally, the RIPE NCC will be unable to enforce these resource holders to maintain accurate data in the registry.
[s/contact/contract/] The proposal mentions "special enduring or temporary circumstances" and also that these be "recognised by the RIPE NCC as being outside the resource holder's control". As I understand it, the intent here is fourfold: - that the RIPE NCC have the freedom to deal appropriately with unforeseen adverse circumstances on a case-by-case basis; - that awareness of this freedom be available to every reader of the policy; - that the RIPE NCC is protected from vexatious or mischievous invocation of this section by the requirement for recognition by the RIPE NCC of the nature of the circumstances; and - that the resource holder has a remedy against unreasonable refusal of this recognition by recourse to the arbitration procedure. It is of the nature of unforeseen circumstances that it may be difficult to think in advance of what they might be. It is not possible, and therefore not necessary, either for the proposers or for the RIPE NCC to itemize in a (final or proposed) policy an exhaustive list of such circumstances. It will be useful to have a list of the Registration Services for which a contract is required.
7. In cases where the Legacy Resource Holder is unknown or unresponsive, the proposal allows for the RIPE NCC to update entries in the RIPE Database but does not specify the scope of these updates.
The fact that a resource holder is unknown or unresponsive should not be an obstacle to the RIPE NCC's exercise of its responsibility for the data it holds. Circumstances may arise in which there is a compelling reason for the RIPE NCC to make an update. The RIPE NCC is empowered and trusted to act responsibly.
8. The provision of some RIPE NCC services is dependent on whether the resources are PA or PI. The RIPE NCC will require clear guidelines on the terms under which Legacy Internet Resources would be offered these services.
Only Registration Services are within scope for this proposal. Legacy resources are neither PA nor PI, but LEGACY, and need to be supported by Registration Services. If the policy proposal is unclear, it will be helpful to have this indicated, either by reference to more detailed text in the current Impact Assessment, or by further clarification. Otherwise, the preparation of operational guidelines consistent with RIPE policy as developed from time to time, seems to me to be the responsibility of the RIPE NCC, subject to due oversight and confirmation from the community.
9. Currently arbitration does not apply to Legacy Internet Resources. Amendments to the arbitration procedure are subject to approval by the GM.
Please see my comment to point 4.
10. If the proposal is accepted, the RIPE NCC will have to contact Legacy Resource Holders that have their resources registered under the umbrella of an LIR and offer them the contractual options of the accepted proposal. The RIPE NCC will consider any requests for this since 1992 as having never been submitted.
If such a LIR is acting as an ad-hoc registration intermediary, the situation may be seen as sufficiently irregular as to require attention whether or not the proposal is accepted. Otherwise, a variation to a Sponsoring-LIR agreement will be needed, which is the responsibility of each LIR involved. I'ld like to have further explanation of the last sentence, referring to 1993, as I don't understand it.
11. If the community decides that this proposal should allow for the certification of Legacy Internet Resources, the RIPE NCC will need to create a certification system specific to these resources.
Probably. I understand that another current proposal aims to allow certification of PI resources. It may be opportune to create a multivalent certification system supporting different kinds of resources.
12. The RIPE NCC is seeking guidance from the community on who should be considered the legitimate holder of Legacy Internet Resources that have been distributed through several layers of hierarchy.
This is a significant problem, which arises whether or not the current policy proposal is accepted. I'm not sure what specific impact this policy proposal has on the problem. I can see that it changes the context, but neither that it makes the problem either more or less intractable nor that it affects the nature of the work to be done.
13. RIPE Database objects referring to Legacy Internet Resources currently have several different "status:" attribute values. The RIPE NCC proposes changing these to 'LEGACY'.
This seems reasonable.
14. The RIPE NCC also proposes introducing a mandatory "status:" attribute for all AUT-NUM objects which would take the value 'LEGACY' for all legacy AS numbers. For all other AS numbers the values would either be set to 'ASSIGNED' (assigned by the RIPE NCC) or 'OTHER' (assigned by other RIRs).
This also seems reasonable. Best regards, Niall O'Reilly
Hi Niall, Replying as an individual as well:
1. The proposal refers to the terms and conditions under which the Legacy Internet Resources were originally granted. The RIPE NCC will need to be informed as to the content of these original terms and conditions to properly determine their impact.
This need seems to be overstated. Beyond what is necessary to determine whether the party involved is indeed the legitimate holder of the resource in question, what need can the RIPE NCC have for the information mentioned?
Indeed. The NCC needs to know who is the holder to keep the database up to date and to provide services. The terms and conditions are not going to be enforced by the NCC, so why would they need them?
2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests.
This is information of which I was not previously aware. I appreciate being made aware of this and intend to ensure that it is taken into account during the proposal's next revision cycle.
As long as those Legacy Resource Holders know that they don't *have* to do this to get services from the NCC then that should indeed be up to them.
3. Due diligence checks will be required to verify the legitimacy of Legacy Resource Holders. If the correct documentation cannot be provided, the RIPE NCC will be unable to enter into a contractual relationship with the Legacy Resource Holder.
To the extent the the diligence applied is indeed "due", and conforms with reality rather than with some conventional concept or recipe, this seems reasonable. Due diligence needs to be informed by both Balance of Probability and Balance of Convenience.
It seems to me that a test which the RIPE NCC might reasonably use would be whether sufficient trust exists for a good-faith belief in the legitimacy of the claim to hold the resources in question.
I expect that the issue here is whether the RIPE NCC can safely offer registration services (possibly including certification) in each specific case.
This is a very hard thing to define in policy. Looking back at the previous item: "The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC.". I assume that for this even stricter checks are in place. That should be the upper limit of the due diligence. I don't want to define in policy how the NCC should handle this though.
4. Section 2.1 of the proposal allows Legacy Internet Resources to be covered by the RIPE NCC Standard Service Agreement (SSA). Modifications to the SSA will require approval by the General Meeting (GM).
The GM has the necessary power.
I expect that it will be for a member with some interest in legacy resources to bring forward a proposal that the GM exercise this power.
+1
5. Section 2.4 of the proposal allows the Legacy Resource Holder to engage directly with the RIPE NCC through a special contract if they cannot find a sponsoring LIR. The RIPE NCC cannot think of any circumstances where this might be the case. Also, the creation of such a special class of contract would require approval by the GM.
My remark to point 4 applies also to point 5.
+1
6. Similarly, section 2.5 allows the Legacy Resource Holder to conclude no contact due to special enduring circumstances. The RIPE NCC cannot think of what these circumstances might be, and some Registration Services cannot be performed without a contract in place. Additionally, the RIPE NCC will be unable to enforce these resource holders to maintain accurate data in the registry.
[s/contact/contract/]
The proposal mentions "special enduring or temporary circumstances" and also that these be "recognised by the RIPE NCC as being outside the resource holder's control".
As I understand it, the intent here is fourfold:
- that the RIPE NCC have the freedom to deal appropriately with unforeseen adverse circumstances on a case-by-case basis;
- that awareness of this freedom be available to every reader of the policy;
- that the RIPE NCC is protected from vexatious or mischievous invocation of this section by the requirement for recognition by the RIPE NCC of the nature of the circumstances; and
- that the resource holder has a remedy against unreasonable refusal of this recognition by recourse to the arbitration procedure.
It is of the nature of unforeseen circumstances that it may be difficult to think in advance of what they might be. It is not possible, and therefore not necessary, either for the proposers or for the RIPE NCC to itemize in a (final or proposed) policy an exhaustive list of such circumstances.
Making such a list would be a very bad idea. It will provide opportunities to be abused ("but according to this list I ...") and it will exclude cases that we haven't thought of. The policy should set the framework for the NCC to be able to deal with these cases.
It will be useful to have a list of the Registration Services for which a contract is required.
Make that a maintained and published list.
7. In cases where the Legacy Resource Holder is unknown or unresponsive, the proposal allows for the RIPE NCC to update entries in the RIPE Database but does not specify the scope of these updates.
The fact that a resource holder is unknown or unresponsive should not be an obstacle to the RIPE NCC's exercise of its responsibility for the data it holds. Circumstances may arise in which there is a compelling reason for the RIPE NCC to make an update. The RIPE NCC is empowered and trusted to act responsibly.
Same as before: the NCC is the caretaker of our RIPE Database. If the NCC needs to update the database to improve accuracy then I don't see why we would limit that to a smaller scope than 'the RIPE database'.
8. The provision of some RIPE NCC services is dependent on whether the resources are PA or PI. The RIPE NCC will require clear guidelines on the terms under which Legacy Internet Resources would be offered these services.
Only Registration Services are within scope for this proposal.
Legacy resources are neither PA nor PI, but LEGACY, and need to be supported by Registration Services.
If the policy proposal is unclear, it will be helpful to have this indicated, either by reference to more detailed text in the current Impact Assessment, or by further clarification.
Otherwise, the preparation of operational guidelines consistent with RIPE policy as developed from time to time, seems to me to be the responsibility of the RIPE NCC, subject to due oversight and confirmation from the community.
Saying that "resources are PA or PI" is indeed too limiting here. If this policy is accepted then the NCC needs to be able to handle LEGACY resources as well.
9. Currently arbitration does not apply to Legacy Internet Resources. Amendments to the arbitration procedure are subject to approval by the GM.
Please see my comment to point 4.
+1
10. If the proposal is accepted, the RIPE NCC will have to contact Legacy Resource Holders that have their resources registered under the umbrella of an LIR and offer them the contractual options of the accepted proposal. The RIPE NCC will consider any requests for this since 1992 as having never been submitted.
If such a LIR is acting as an ad-hoc registration intermediary, the situation may be seen as sufficiently irregular as to require attention whether or not the proposal is accepted.
Otherwise, a variation to a Sponsoring-LIR agreement will be needed, which is the responsibility of each LIR involved.
I'ld like to have further explanation of the last sentence, referring to 1993, as I don't understand it.
I guess that was when the NCC started. Explicitly saying that instead of mentioning a specific year would be better if I'm right. Otherwise: NCC: please explain the intention.
11. If the community decides that this proposal should allow for the certification of Legacy Internet Resources, the RIPE NCC will need to create a certification system specific to these resources.
Probably.
I understand that another current proposal aims to allow certification of PI resources. It may be opportune to create a multivalent certification system supporting different kinds of resources.
As both PI and LEGACY resources allow the use of a Sponsoring LIR I would imagine the implementation to be roughly the same. What would be so special about legacy resources that it would need a certification system specific to those resources?
12. The RIPE NCC is seeking guidance from the community on who should be considered the legitimate holder of Legacy Internet Resources that have been distributed through several layers of hierarchy.
This is a significant problem, which arises whether or not the current policy proposal is accepted.
I'm not sure what specific impact this policy proposal has on the problem. I can see that it changes the context, but neither that it makes the problem either more or less intractable nor that it affects the nature of the work to be done.
The NCC already handles Legacy Resource Holders who want their resources to be treated as resources allocated by the RIPE NCC (see item 3). The procedures that are used for that would be a good starting point I guess. I think this guidance should not be put into policy at this point in time. For further guidance it might be useful to discuss this at a future RIPE meeting.
13. RIPE Database objects referring to Legacy Internet Resources currently have several different "status:" attribute values. The RIPE NCC proposes changing these to 'LEGACY'.
This seems reasonable.
+1
14. The RIPE NCC also proposes introducing a mandatory "status:" attribute for all AUT-NUM objects which would take the value 'LEGACY' for all legacy AS numbers. For all other AS numbers the values would either be set to 'ASSIGNED' (assigned by the RIPE NCC) or 'OTHER' (assigned by other RIRs).
This also seems reasonable.
+1 Thank you! Sander
On Fri, May 10, 2013 at 03:14:59PM +0200, Sander Steffann wrote:
This need seems to be overstated. Beyond what is necessary to determine whether the party involved is indeed the legitimate holder of the resource in question, what need can the RIPE NCC have for the information mentioned?
Indeed. The NCC needs to know who is the holder to keep the database up to date and to provide services. The terms and conditions are not going to be enforced by the NCC, so why would they need them?
+1 The T&C of the original assignment are not relevant to the provision of services by the NCC and may, after all the years, not even be available anymore. Thus, the requirement is unneccessary and onerous.
3. Due diligence checks will be required to verify the legitimacy of Legacy Resource Holders. If the correct documentation cannot be provided, the RIPE NCC will be unable to enter into a contractual relationship with the Legacy Resource Holder.
[...]
checks are in place. That should be the upper limit of the due diligence. I don't want to define in policy how the NCC should handle this though.
+1 I'm also in favour of setting limits on how much verification the NCC can require (and to have some kind of oversight by the membership) My nightmare scenario here is requiring legal proof of the entire chain of M&A that led to the current entity being the holder of a resource. [Exhaustive list of circumstances where 2.6 applies]
Making such a list would be a very bad idea. It will provide opportunities to be abused ("but according to this list I ...") and it will exclude cases that we haven't thought of. The policy should set the framework for the NCC to be able to deal with these cases.
+1 It may well be the case that this list would have as many entries as there are legacy holders. This would be pretty pointless. Every such case must be decided on its own merits and, most importantly, there MUST be an appeals process, possibly via the arbitration procedure.
It will be useful to have a list of the Registration Services for which a contract is required.
Make that a maintained and published list.
+1 rgds, Sascha Luck
At 13:27 10/05/2013 +0100, Niall O'Reilly wrote:
2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests.
This is information of which I was not previously aware. I appreciate being made aware of this and intend to ensure that it is taken into account during the proposal's next revision cycle.
To what benefit would one receive to have the resource considered as space allocated by RIPE NCC? Perhaps the RIPE NCC can provide some examples so we can understand this.
8. The provision of some RIPE NCC services is dependent on whether the resources are PA or PI. The RIPE NCC will require clear guidelines on the terms under which Legacy Internet Resources would be offered these services.
Only Registration Services are within scope for this proposal.
Legacy resources are neither PA nor PI, but LEGACY, and need to be supported by Registration Services.
+1. -Hank
On 10 May 2013, at 14:39, Hank Nussbacher wrote:
At 13:27 10/05/2013 +0100, Niall O'Reilly wrote:
2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests.
This is information of which I was not previously aware. I appreciate being made aware of this and intend to ensure that it is taken into account during the proposal's next revision cycle.
To what benefit would one receive to have the resource considered as space allocated by RIPE NCC? Perhaps the RIPE NCC can provide some examples so we can understand this.
+1 OTOH, if a resource holder, fully aware of the consequences, chooses to make such a request, we should perhaps not propose policy which would force the NCC to decline it. Whether the choice were an informed one might be a concern. /Niall
2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests. This is information of which I was not previously aware. I appreciate being made aware of this and intend to ensure that it is taken into account during the proposal's next revision cycle. To what benefit would one receive to have the resource considered as space allocated by RIPE NCC? Perhaps the RIPE NCC can provide some examples so we can understand this. +1
if such a case existed, would they not just become a member? randy
Hi Randy,
To what benefit would one receive to have the resource considered as space allocated by RIPE NCC? Perhaps the RIPE NCC can provide some examples so we can understand this. +1
if such a case existed, would they not just become a member?
If I understand correctly they do become a member and have their legacy address space re-labeled as PA space. NCC: please correct me if I'm wrong! Sander
On 10/05/2013 17:47, Sander Steffann wrote:
If I understand correctly they do become a member and have their legacy address space re-labeled as PA space.
NCC: please correct me if I'm wrong!
There's no facility in this proposal to get your legacy address space relabelled as PA. This is probably an omission and it would be good to put the practice of doing this on a formal policy basis. Nick
Hi Nick,
There's no facility in this proposal to get your legacy address space relabelled as PA. This is probably an omission and it would be good to put the practice of doing this on a formal policy basis.
Niall already responded to that:
2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests.
This is information of which I was not previously aware. I appreciate being made aware of this and intend to ensure that it is taken into account during the proposal's next revision cycle.
Cheers, See you in Dublin! Sander
Sander Steffann wrote:
Hi Randy,
To what benefit would one receive to have the resource considered as space allocated by RIPE NCC?
IMHO, with the *current* set of address transfer provisions, it would open the possibility to transfer (parts of) these addresses.
Perhaps the RIPE NCC can provide some
examples so we can understand this.
+1
if such a case existed, would they not just become a member?
But, to add another littel bit of Internet Archeology info here. I did establish our LIR in early 1993. Back then, there was no concept of PI and PA, yet. What we had was ISP-based LIRs, last-resort-LIRs on a per country basis, and in parallel, other mechanisms to obtain blocks of addresses[1]. Thus, initially, our allocation was "unlabelled" and with the introduction of this attribute, became status: "ALLOCATED UNSPECIFIED". As we were operating this LIR on the procedures of an ISP-based LIR, and thus "PA", eventually we asked/agreed with the NCC to change the status to "ALLOCATED PA" :-) Those were the times... ;-)
If I understand correctly they do become a member and have their legacy address space re-labeled as PA space.
NCC: please correct me if I'm wrong! Sander
What I want to achieve with this stuff: back then the world looked a tad different. There were no "service contracts", formal agreements or "terms and conditions" and a full paper trail. In particular for those resources obtained outside the framework of the NCC. IMHO, any attempt to "manage" eligibility for the registration services based on today's strict formalities, is going to give us grief - big time. Wilfried. [1] the only distinction back then (with "cc" as ISO3166 country codes) was the ° RegID: "cc"."isptag" for the ISP-based which later became the LIRs with PA, and ° RegID: "cc".ZZ were the last-resort, which were a precursor of PI stuff
8. The provision of some RIPE NCC services is dependent on whether the resources are PA or PI. The RIPE NCC will require clear guidelines on the terms under which Legacy Internet Resources would be offered these services.
Legacy resources are neither PA nor PI, but LEGACY, and need to be supported by Registration Services.
how about PR, Pre RIR :) in trying to understand the impact statement, it was hard for me to separate concerns about any insufficiently precise semantics of the proposal from any actual impact it might have. the above is a case in point. i was expecting "a third class of address space may need the following changes in database, processes, ..." randy
On Fri, May 10, 2013 at 01:27:43PM +0100, Niall O'Reilly wrote:
4. Section 2.1 of the proposal allows Legacy Internet Resources to be covered by the RIPE NCC Standard Service Agreement (SSA). Modifications to the SSA will require approval by the General Meeting (GM).
The GM has the necessary power.
I expect that it will be for a member with some interest in legacy resources to bring forward a proposal that the GM exercise this power.
+1
7. In cases where the Legacy Resource Holder is unknown or unresponsive, the proposal allows for the RIPE NCC to update entries in the RIPE Database but does not specify the scope of these updates.
The fact that a resource holder is unknown or unresponsive should not be an obstacle to the RIPE NCC's exercise of its responsibility for the data it holds. Circumstances may arise in which there is a compelling reason for the RIPE NCC to make an update. The RIPE NCC is empowered and trusted to act responsibly.
This would appear to empower the NCC to unilaterally, de-register or even re-register such resources. (which is, IIRC, what the NCC originally proposed and what triggered this proposal) Maybe we should limit this to changing the relevant objects to "Unknown" or similar...
8. The provision of some RIPE NCC services is dependent on whether the resources are PA or PI. The RIPE NCC will require clear guidelines on the terms under which Legacy Internet Resources would be offered these services.
Only Registration Services are within scope for this proposal.
Legacy resources are neither PA nor PI, but LEGACY, and need to be supported by Registration Services.
+1
10. If the proposal is accepted, the RIPE NCC will have to contact Legacy Resource Holders that have their resources registered under the umbrella of an LIR and offer them the contractual options of the accepted proposal. The RIPE NCC will consider any requests for this since 1992 as having never been submitted.
If such a LIR is acting as an ad-hoc registration intermediary, the situation may be seen as sufficiently irregular as to require attention whether or not the proposal is accepted.
Otherwise, a variation to a Sponsoring-LIR agreement will be needed, which is the responsibility of each LIR involved.
If such registrations have been previously accepted by the NCC they should be considered valid (subject to the above mentioned agreement variation) This shouldn't preclude offering the resource holder the other contractual options, but should give them the option to continue their existing relationship without going through another full registration process.
13. RIPE Database objects referring to Legacy Internet Resources currently have several different "status:" attribute values. The RIPE NCC proposes changing these to 'LEGACY'.
This seems reasonable.
+1
14. The RIPE NCC also proposes introducing a mandatory "status:" attribute for all AUT-NUM objects which would take the value 'LEGACY' for all legacy AS numbers. For all other AS numbers the values would either be set to 'ASSIGNED' (assigned by the RIPE NCC) or 'OTHER' (assigned by other RIRs).
This also seems reasonable.
+1 rgds, Sascha Luck
Hi Sasha,
This would appear to empower the NCC to unilaterally, de-register or even re-register such resources. (which is, IIRC, what the NCC originally proposed and what triggered this proposal) Maybe we should limit this to changing the relevant objects to "Unknown" or similar...
I think that is too limiting. We should limit the NCC to putting in accurate information. Deregistration would then only be possible if the NCC *knows* nobody is using that resource anymore, and I see no problem with that. (the problem will be finding proof, not the deregistration itself) Cheers, Sander
On 10 maj 2013, at 14:27, Niall O'Reilly <Niall.oReilly@ucd.ie> wrote:
4. Section 2.1 of the proposal allows Legacy Internet Resources to be covered by the RIPE NCC Standard Service Agreement (SSA). Modifications to the SSA will require approval by the General Meeting (GM).
The GM has the necessary power.
I expect that it will be for a member with some interest in legacy resources to bring forward a proposal that the GM exercise this power.
I'll just make the observation that this though makes the implementation of the policy dependent on action that is not under the control of the neither the PDP or the RIPE NCC staff. Best regards, - kurtis -
Hi,
4. Section 2.1 of the proposal allows Legacy Internet Resources to be covered by the RIPE NCC Standard Service Agreement (SSA). Modifications to the SSA will require approval by the General Meeting (GM).
The GM has the necessary power.
I expect that it will be for a member with some interest in legacy resources to bring forward a proposal that the GM exercise this power.
I'll just make the observation that this though makes the implementation of the policy dependent on action that is not under the control of the neither the PDP or the RIPE NCC staff.
Yeah, difficult, but that's how it works. We had the same issue with 2007-01 in APWG, and it worked out in the end. The best way forward is to work with the NCC Board once the wishes of the community are clear. The board can then let the NCC members vote on whatever is necessary at an AGM. Met vriendelijke groet, Sander Steffann
On 13 maj 2013, at 15:25, Sander Steffann <sander@steffann.nl> wrote:
4. Section 2.1 of the proposal allows Legacy Internet Resources to be covered by the RIPE NCC Standard Service Agreement (SSA). Modifications to the SSA will require approval by the General Meeting (GM).
The GM has the necessary power.
I expect that it will be for a member with some interest in legacy resources to bring forward a proposal that the GM exercise this power.
I'll just make the observation that this though makes the implementation of the policy dependent on action that is not under the control of the neither the PDP or the RIPE NCC staff.
Yeah, difficult, but that's how it works. We had the same issue with 2007-01 in APWG, and it worked out in the end. The best way forward is to work with the NCC Board once the wishes of the community are clear. The board can then let the NCC members vote on whatever is necessary at an AGM.
Absolutely, I just wanted to highlight the process, nothing else. Best regards, - kurtis -
Hi, First of all, sorry for being a bit late to jump in on the proposal. https://www.ripe.net/ripe/policies/proposals/2012-07/draft I had a question on the procedures, when this proposal is accepted. Is it the intention of the RIPE NCC to go back to ALL legacy resource holders (including those that have signed the 'Legacy Space Agreement' or 'Agreement between Legacy Holder and LIR' ( see the downloads of the templates here : http://www.ripe.net/lir-services/resource-management/legacy-space ) to ask them if they would want to revert their decision and get their original LEGACY status back on their resources under this policy instead of the status: Allocated PA or Assigned PI? The reason why I ask this, as there might be original Legacy space holders who might think that the current proposal would be a better solution (fit) than the current implemented (signed) agreement. I noticed point 10 in the Executive Summary: 10. If the proposal is accepted, the RIPE NCC will have to contact Legacy Resource Holders that have their resources registered under the umbrella of an LIR and offer them the contractual options of the accepted proposal. The RIPE NCC will consider any requests for this since 1992 as having never been submitted. But does that include ALL Legacy resource holders even those that are not registered under a LIR? One of the other (small) points that I had some questions about is point 2 in the Executive summary: 2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests. Why would the RIPE NCC have to decline these requests? I also have a question on the topic A Understanding the policy: This policy proposal is meant to be applied by the RIPE NCC to Registration Services, as regards Legacy Internet Resources. > Legacy Internet Resources – as defined in this proposal, are any Internet resources obtained prior to (or otherwise outside of) the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries (RIRs). While this definition is not limited to resources in the RIPE Registry, the RIPE NCC does not have authority over Legacy Internet Resources in other registries. If this proposal is accepted, the RIPE NCC will implement it only to Legacy Internet Resources that are currently registered in the RIPE Registry. If there are Legacy Internet Resources currently registered at ARIN for instance and a legitimate holder wants to have their resource registered in the RIPE registry, why would it not be available for those registrations? Regards, Erik Bais
On 10 Jun 2013, at 10:30, Erik Bais wrote:
Hi,
First of all, sorry for being a bit late to jump in on the proposal.
https://www.ripe.net/ripe/policies/proposals/2012-07/draft
I had a question on the procedures, when this proposal is accepted.
Your questions seem to be based on the RIPE NCC's Impact Assessment, rather than on the actual text of the proposal. Because of this, I think it's better for me to leave it to the NCC to answer them rather than to jump in with reactions based on what I think they may have meant. I will make just one exception, where your question refers to a reaction from the NCC which pointed out a gap in the proposal.
One of the other (small) points that I had some questions about is point 2 in the Executive summary:
2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests.
Why would the RIPE NCC have to decline these requests?
As written, v3.0 of proposal 2012-07 didn't provide such an option, simply because the authors hadn't considered it. NCC read this as an obstacle to accepting such a request in future. The draft currently in preparation provides explicitly for this case, so that the obstacle should no longer arise. Thanks for asking, Erik. Niall O'Reilly
Hi Erik, On 6/10/13 11:30 AM, Erik Bais wrote:
Hi,
First of all, sorry for being a bit late to jump in on the proposal.
https://www.ripe.net/ripe/policies/proposals/2012-07/draft
I had a question on the procedures, when this proposal is accepted.
Is it the intention of the RIPE NCC to go back to ALL legacy resource holders (including those that have signed the 'Legacy Space Agreement' or 'Agreement between Legacy Holder and LIR' ( see the downloads of the templates here : http://www.ripe.net/lir-services/resource-management/legacy-space ) to ask them if they would want to revert their decision and get their original LEGACY status back on their resources under this policy instead of the status: Allocated PA or Assigned PI?
The reason why I ask this, as there might be original Legacy space holders who might think that the current proposal would be a better solution (fit) than the current implemented (signed) agreement.
I noticed point 10 in the Executive Summary:
10. If the proposal is accepted, the RIPE NCC will have to contact Legacy Resource Holders that have their resources registered under the umbrella of an LIR and offer them the contractual options of the accepted proposal. The RIPE NCC will consider any requests for this since 1992 as having never been submitted.
But does that include ALL Legacy resource holders even those that are not registered under a LIR?
If this policy reaches consensus the RIPE NCC will contact legacy resource holders that over time have either: - registered their address space with an LIR; and/or - signed one of the agreements mentioned above in order to inform them that those agreements and registrations will be considered as never having been submitted and offer them the options listed in the accepted policy. Furthermore the RIPE NCC will send an email to the contacts registered in all other legacy resource RIPE Database objects, informing them about the options listed in the accepted policy.
One of the other (small) points that I had some questions about is point 2 in the Executive summary:
2. The RIPE NCC often receives requests from Legacy Resource Holders wanting their resources to be considered as space allocated by the RIPE NCC. If this proposal is accepted, the RIPE NCC will have to decline these requests.
Why would the RIPE NCC have to decline these requests?
I believe that Niall has already addressed this question.
I also have a question on the topic A Understanding the policy:
This policy proposal is meant to be applied by the RIPE NCC to Registration Services, as regards Legacy Internet Resources.
Legacy Internet Resources – as defined in this proposal, are any Internet resources obtained prior to (or otherwise outside of) the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries (RIRs). While this definition is not limited to resources in the RIPE Registry, the RIPE NCC does not have authority over Legacy Internet Resources in other registries. If this proposal is accepted, the RIPE NCC will implement it only to Legacy Internet Resources that are currently registered in the RIPE Registry.
If there are Legacy Internet Resources currently registered at ARIN for instance and a legitimate holder wants to have their resource registered in the RIPE registry, why would it not be available for those registrations?
Legacy resources issued to organisations within the RIPE region have been transferred to the RIPE region during the ERX project. Legacy resources that have not been transferred at that time, have been issued and registered to organisations in other RIR regions. RIPE policy has no authority over legacy resources registered in other RIR regions. For this reason, in order to transfer those resources to the RIPE registry (and register them with a RIPE NCC LIR), there needs to be a transfer policy that would allow transfers between the RIPE NCC and the RIR that has the authority over those resources. I hope this clarifies. Best regards, Andrea Cima RIPE NCC
Regards, Erik Bais
participants (11)
-
Andrea Cima -
Emilio Madaio -
Erik Bais -
Hank Nussbacher -
Lindqvist Kurt Erik -
Niall O'Reilly -
Nick Hilliard -
Randy Bush -
Sander Steffann -
Sascha Luck -
Wilfried Woeber