comments on proposal 2012-07
Hello, I thought I'd chip in on 2012-07. The current version of the proposal is a huge improvement on v1.0 and thanks / kudos need to go to the authors for what was obviously a huge amount of work. I still have issues with a number of areas. Serious issues: Section 3.0 needs to include a term in the contract to state that the services provided by the RIPE NCC to the legacy resource holder are defined by RIPE community policy and may be amended from time to time, according to ripe community policy. Section 2.6 still provides carte blanche for legacy resource holders to freeload services off the RIPE NCC with no consequences. As a RIPE NCC member, I am not at all happy about this. The amount of work that the RIPE NCC is going to have to undertake to handle the legacy resource holder community is very large indeed, and it is not reasonable to expect the RIPE membership to foot the bill for those legacy resource holders who aren't members and who feel un-inclined to contribute towards registration services just because they couldn't be bothered to pay. Section 2.5: I see where this is coming from, namely there will probably be situations where the users of the address space will be unable to identify themselves adequately as having any claim to their assignment. However, this section is open to abuse and it concerns me that it's still there. I concede that there is a requirement to have some type of arrangement like this, but the wording of the current section needs to be tightened up considerably. Less serious issues: Section 2.4 is redundant. We have a well established precedent under the terms of 2007-01 for engaging with sponsoring LIRs and this seems to work well in practice. Creating this policy option merely adds cost to the RIPE NCC's bottom line for no gain. Nits: Section 3.0: "a statement that the RIPE NCC is not entitled to deregister the resources for whatever purpose unless so instructed by the resource holder". This statement is advisory only and it needs to be made clear that the sponsoring LIR does not have power to make a legally binding statement of this form. This actually applies to all four statements in section 3.0. Nick
Hi Nick,
Section 2.6 still provides carte blanche for legacy resource holders to freeload services off the RIPE NCC with no consequences.
Not really. It maintains the current situation. We cannot force a legacy resource holder to sign a contract. In that case all services could be withdrawn, but that would not be in the best interest of the community. Keeping the database up to date is in everybody's best interest. The other service that a legacy resource holder already might have is reverse DNS. Withdrawing that would be a bit silly as it is already in place and doesn't cost any significant amount. And the RIPE NCC "will have no obligation to begin to provide any registry service element not already provided in support of a particular Legacy Internet Resource", so everything else is not part of 2.6. If a legacy resource holder wants anything more they will have to choose one of the other options.
As a RIPE NCC member, I am not at all happy about this. The amount of work that the RIPE NCC is going to have to undertake to handle the legacy resource holder community is very large indeed, and it is not reasonable to expect the RIPE membership to foot the bill for those legacy resource holders who aren't members and who feel un-inclined to contribute towards registration services just because they couldn't be bothered to pay.
I hope I have shown above that there is not much of a bill for this, and the little bill there might be is in the best interest of the community.
Section 2.5: I see where this is coming from, namely there will probably be situations where the users of the address space will be unable to identify themselves adequately as having any claim to their assignment. However, this section is open to abuse and it concerns me that it's still there. I concede that there is a requirement to have some type of arrangement like this, but the wording of the current section needs to be tightened up considerably.
It only applies to "specific enduring or temporary circumstances which are recognized by the RIPE NCC as being outside the resource holder's control". Any attempt to use this section must be recognised/approved by the NCC. How is this open to abuse if it only applies to circumstances outside the resource holder's control?
Less serious issues:
Section 2.4 is redundant. We have a well established precedent under the terms of 2007-01 for engaging with sponsoring LIRs and this seems to work well in practice. Creating this policy option merely adds cost to the RIPE NCC's bottom line for no gain.
This option actually comes from 2007-01, which created RIPE-452: http://www.ripe.net/ripe/docs/ripe-452. RIPE-452 states: "End Users of provider independent resources are responsible for maintaining a contractual link to the RIPE NCC either through a sponsoring LIR or else directly to the RIPE NCC for the purposes of managing these resources.". So to be consistent with 2007-01 this option has to be present. Cheers, Sander
On 01/11/2013 17:27, Sander Steffann wrote:
Section 2.4 is redundant. We have a well established precedent under the terms of 2007-01 for engaging with sponsoring LIRs and this seems to work well in practice. Creating this policy option merely adds cost to the RIPE NCC's bottom line for no gain.
This option actually comes from 2007-01, which created RIPE-452:
It does indeed - the point wasn't lost on me. However the NCC membership approved an NCC board proposal in Nov 2011 that it would no longer provide this option, and now there is no such option available for PI holders. In retrospect I think this is a more sensible way of handling the contractual relationship. Nick
Hi,
It does indeed - the point wasn't lost on me. However the NCC membership approved an NCC board proposal in Nov 2011 that it would no longer provide this option, and now there is no such option available for PI holders. In retrospect I think this is a more sensible way of handling the contractual relationship.
The RIPE community makes RIPE policy, and the NCC should implement it. Not the other way around... Now it might be wise for the community to listen to the NCC's advise about this, but this is not the place to change that. If people think this option should no longer be offered then that should be done with a separate policy proposal that changes it for all RIPE policies. Until that happens the same options should be offered everywhere to keep RIPE policy consistent. Cheers, Sander
On 01/11/2013 17:55, Sander Steffann wrote:
The RIPE community makes RIPE policy, and the NCC should implement it. Not the other way around... Now it might be wise for the community to listen to the NCC's advise about this, but this is not the place to change that. If people think this option should no longer be offered then that should be done with a separate policy proposal that changes it for all RIPE policies. Until that happens the same options should be offered everywhere to keep RIPE policy consistent.
As I mentioned in my original mail, this is a less serious issue. If we're going to discuss stuff, we should probably not get ratholed down this because its impact is minimal. Nick
Hi,
As I mentioned in my original mail, this is a less serious issue. If we're going to discuss stuff, we should probably not get ratholed down this because its impact is minimal.
I agree. At some point we should get RIPE policy and the RIPE NCC synchronised again, but that is a different discussion :-) Cheers, Sander
On 01/11/2013 17:27, Sander Steffann wrote:
I hope I have shown above that there is not much of a bill for this, and the little bill there might be is in the best interest of the community.
I haven't seen the ripe ncc cost estimates for implementing 2012-07 yet. The costs for 2007-01 were very high though. Nick
Hi,
I haven't seen the ripe ncc cost estimates for implementing 2012-07 yet. The costs for 2007-01 were very high though.
I know, but you are now comparing apples to oranges. The cost of 2007-01 was in establishing contractual relationships with all PI resource holders. We were talking about the cost of legacy resource holders that don't want to sign an agreement and maintain the status-quo. The RIPE NCC doesn't have to do much for those: keep the existing database objects and maybe keep the existing reverse DNS. Nothing else. The major effort will be for those that *do* enter into an agreement (validating their claim to the resources etc), but those will also contribute financially. Just like with 2007-01. Cheers, Sander
On 01/11/2013 18:00, Sander Steffann wrote:
I know, but you are now comparing apples to oranges.
I disagree; according to the impact analysis:
Executive Summary - The RIPE NCC will contact all Legacy Resource Holders and offer them the options listed in the accepted policy. The total number of legacy Internet Resources in the RIPE Registry is approximately 4,200 IP blocks and 740 AS numbers, held by approximately 2,500 organisations.
The cost of this will be highly dependent on the amount of work that the RIPE NCC does here and it's not specified clearly in the impact analysis. As there is no obligation on the RIPE NCC to establish a contractual relationship with the end users for legacy holders, that part of the work load will be less. On the other hand, the data is significantly more stale than the organisations covered by 2007-01. Has the NCC done any cost analysis for handling this proposal? Nick
Hi, Op 1 nov. 2013, om 19:06 heeft Nick Hilliard <nick@netability.ie> het volgende geschreven:
Executive Summary - The RIPE NCC will contact all Legacy Resource Holders and offer them the options listed in the accepted policy. The total number of legacy Internet Resources in the RIPE Registry is approximately 4,200 IP blocks and 740 AS numbers, held by approximately 2,500 organisations.
The cost of this will be highly dependent on the amount of work that the RIPE NCC does here and it's not specified clearly in the impact analysis.
The NCC has to contact all legacy resource holders, no matter what option they choose. What has this cost to do with the options presented to the legacy resource holders?
As there is no obligation on the RIPE NCC to establish a contractual relationship with the end users for legacy holders, that part of the work load will be less. On the other hand, the data is significantly more stale than the organisations covered by 2007-01.
True.
Has the NCC done any cost analysis for handling this proposal?
That is for the NCC to answer. Sander
Hi,
Executive Summary - The RIPE NCC will contact all Legacy Resource Holders and offer them the options listed in the accepted policy. The total number of legacy Internet Resources in the RIPE Registry is approximately 4,200 IP blocks and 740 AS numbers, held by approximately 2,500 organisations.
The cost of this will be highly dependent on the amount of work that the RIPE NCC does here and it's not specified clearly in the impact analysis.
Just to make sure: are you suggesting that the RIPE NCC should *not* contact all legacy resource holders? That would imply that option 2.6 is in effect for every legacy resource holders until they contact the NCC by themselves, which doesn't sound like a sensible option to me... Cheers, Sander
On 01/11/2013 18:50, Sander Steffann wrote:
Just to make sure: are you suggesting that the RIPE NCC should *not* contact all legacy resource holders? That would imply that option 2.6 is in effect for every legacy resource holders until they contact the NCC by themselves, which doesn't sound like a sensible option to me...
Not at all. I'm just saying that this proposal comes with a price tag. As a paying RIPE NCC member, I'd like to know how many zeros we're going to see on that tag, because that will influence how strongly I feel about giving every legacy holder a free-services-forever option under section 2.6. Outside the ongoing costs of running the registry, the impact analysis indicates 700-900 FTE working days for the registry services department (i.e. ~3-4 FTE years) for handling the contact phase and an unspecified but nontrivial amount of work in business applications which relates to providing services for the direct contractual relationship option in section 2.4. Already this is not a small amount of time, money and resources. The 2500 organisations noted in the impact analysis represents about 10% of the total number of organisations that the RIPE NCC deals with (I'm sure there is plenty of overlap). I find it difficult to understand why this 10% have the option of receiving almost the same level of service from the RIPE NCC as the 90% of organisations who pay. Registration services cost money to provide and it is not unreasonable for users of those registration services to contribute to these running costs. Also, despite what has been said by several people about this proposal, there is no real conflict between accurate resource registration and requiring payment for services. I have no issue with anyone being able to update admin / tech contacts or org: entries on a permanent free basis, but this can easily be provided without necessarily creating a permanent commitment to e.g. free reverse DNS or providing authorization for creating route: objects or resource certification or anything else. Legacy resource holders have had twenty something years of free service supported by the rest of the community. It it not unreasonable to require them - all of them, not just the responsible ones that will avail of sections 2.1-2.5 - to contribute a small amount to the cost of running the registry services that they have used and will continue to use in perpetuity. And I believe that this can be done without compromising the aims of registry accuracy. Nick
Hi Nick, Op 1 nov. 2013, om 22:15 heeft Nick Hilliard <nick@netability.ie> het volgende geschreven:
On 01/11/2013 18:50, Sander Steffann wrote:
Just to make sure: are you suggesting that the RIPE NCC should *not* contact all legacy resource holders? That would imply that option 2.6 is in effect for every legacy resource holders until they contact the NCC by themselves, which doesn't sound like a sensible option to me...
Not at all. I'm just saying that this proposal comes with a price tag. As a paying RIPE NCC member, I'd like to know how many zeros we're going to see on that tag, because that will influence how strongly I feel about giving every legacy holder a free-services-forever option under section 2.6.
Please don't confuse things like this. Option 2.6 is only there so that we don't cripple the database by taking away things that are already there... This policy proposal builds the foundations for legacy resource holders to work together with the RIPE NCC, although legacy resource holders cannot be forced into an agreement: The legacy resource holders had their resources before the NCC started, and the NCC assumed responsibility for maintaining the database for legacy address space. The NCC has an obligation to the community (not only to its members) of running a correct registry. Option 2.6 recognises that: legacy resource holders that don't want to participate don't get any rights to new services, but the registry will be maintained.
Outside the ongoing costs of running the registry, the impact analysis indicates 700-900 FTE working days for the registry services department (i.e. ~3-4 FTE years) for handling the contact phase and an unspecified but nontrivial amount of work in business applications which relates to providing services for the direct contractual relationship option in section 2.4. Already this is not a small amount of time, money and resources.
Yes, if we want to contact the legacy holders then the NCC will have to spend time on it. part of our (I am an LIR too, as a single-person company, so it is not a trivial amount of money for me) contribution to the NCC will be used for this, yes. But the only way to not have these costs is to not contact legacy resource holders at all and keep the status-quo. A lot of legacy resource holders are *participating* and propose 2012-07 because they *want* to work with the NCC. I really don't see your point. What do you want? - Force legacy resource holders to enter into an agreement? That is legally not possible because the RIPE NCC never provided the resources to them and cannot now claim to have authority over them. - Refuse to cooperate with legacy resource holders? Don't provide any services to them? That would mess up the registry that the NCC is supposed to maintain for the community (not just its members) - Work with legacy resource holders that want to participate, and do the minimum (keep the registry up to date but nothing else) for those that don't? That is exactly what 2012-07 is doing...
The 2500 organisations noted in the impact analysis represents about 10% of the total number of organisations that the RIPE NCC deals with (I'm sure there is plenty of overlap). I find it difficult to understand why this 10% have the option of receiving almost the same level of service from the RIPE NCC as the 90% of organisations who pay. Registration services cost money to provide and it is not unreasonable for users of those registration services to contribute to these running costs.
Also, despite what has been said by several people about this proposal, there is no real conflict between accurate resource registration and requiring payment for services. I have no issue with anyone being able to update admin / tech contacts or org: entries on a permanent free basis, but this can easily be provided without necessarily creating a permanent commitment to e.g. free reverse DNS or providing authorization for creating route: objects or resource certification or anything else.
Where did you get that idea? I keep telling you: they don't get anything new under option 2.6, certainly not certification. Just maintaining the registry and possible reverse DNS if they already have it. No resource certification, not anything else. Because they don't have those services now, and they won't get them in the future if they choose option 2.6.
Legacy resource holders have had twenty something years of free service supported by the rest of the community. It it not unreasonable to require them - all of them, not just the responsible ones that will avail of sections 2.1-2.5 - to contribute a small amount to the cost of running the registry services that they have used and will continue to use in perpetuity. And I believe that this can be done without compromising the aims of registry accuracy.
Sorry, but you are just plain wrong here. But I think I explained that above already... Sander
On 01/11/2013 21:49, Sander Steffann wrote:
Please don't confuse things like this. Option 2.6 is only there so that we don't cripple the database by taking away things that are already there...
There's no confusion: I'm aware of what I'm suggesting.
This policy proposal builds the foundations for legacy resource holders to work together with the RIPE NCC, although legacy resource holders cannot be forced into an agreement: The legacy resource holders had their resources before the NCC started, and the NCC assumed responsibility for maintaining the database for legacy address space. The NCC has an obligation to the community (not only to its members) of running a correct registry.
yep, agreed completely.
Option 2.6 recognises that: legacy resource holders that don't want to participate don't get any rights to new services, but the registry will be maintained.
I've addressed the issue before. The root of my objection is that there is no quid pro quo, and this proposal formalises this situation in such a way that it will not be possible to change it in future. Because of the way that the PDP works, any future attempt to change this situation will be shot down. So in essence, LRHs who opt for or fall into section 2.6 and decide that they aren't going to bother to fund the services they use, will be rewarded for doing so by being given free service in perpetuity. This is an objectively unfair proposition - namely it lacks quid pro quo, one of the universally accepted cornerstones of a good quality terms-of-service arrangement. But the proposal is fixable within the terms that we all agree on, namely that the registry accuracy is given highest priority.
- Force legacy resource holders to enter into an agreement? That is legally not possible because the RIPE NCC never provided the resources to them and cannot now claim to have authority over them.
- Refuse to cooperate with legacy resource holders? Don't provide any services to them? That would mess up the registry that the NCC is supposed to maintain for the community (not just its members)
- Work with legacy resource holders that want to participate, and do the minimum (keep the registry up to date but nothing else) for those that don't? That is exactly what 2012-07 is doing...
I'm proposing that the RIPE NCC lets LRHs update and maintain the registry info for their inetnums, but for those organisations who by default or by choice fall into category 2.6, that (after due effort from the RIPE NCC to engage with them) if they continue to decline to pay for registry services that they lose some services, e.g. reverse dns and/or route: objects for those inetnums. This suggestion is made on a payment for services basis. The RIPE community can continue to acknowledge that RIPE policies do not apply to legacy resource holders, but if these LRHs wish to continue to use the full range of registry services, they will need to pay the RIPE NCC for them. Neither RIPE NCC nor the RIPE community make any claims to the resources in this way, nor is the holder stopped from using the resources in any way they want. This establishes a reasonable balance between the rights of the LRHs and the requirements of the RIPE NCC to provide accurate registry services and operate in a fiscally responsible manner which is kept as objectively fair as possible. Given the precedent of the RIPE NCC in charging €50 per resource for PI address blocks, I doubt if the figures involved are going to be large. I'm aware that this option is unpalatable to some people because no-one likes to have to pay money where they didn't have to before, but some realism would help here: the amount of money we're talking about is going to be vanishingly small, and it is not unreasonable to expect people to pay for services rendered. Quite the opposite, in fact: it is unreasonable to expect the RIPE NCC to provide services for free forever, funded by the NCC membership. Incidentally, I apologise for mixing up certification in my previous email. You're correct that certification can only occur for those organisations who choose options 2.1 through 2.4 and establish a contractual chain to the RIPE NCC. Nick
Hi Nick, Op 2 nov. 2013, om 20:49 heeft Nick Hilliard <nick@netability.ie> het volgende geschreven:
I'm proposing that the RIPE NCC lets LRHs update and maintain the registry info for their inetnums, but for those organisations who by default or by choice fall into category 2.6, that (after due effort from the RIPE NCC to engage with them) if they continue to decline to pay for registry services that they lose some services, e.g. reverse dns and/or route: objects for those inetnums.
I personally find this a bit petty. You seem to have a very different idea about the RIPE database than I have. The RIPE database is a service to the *community*, not only the NCC members. And the database != the registry. There are lots of things in that database: poems, route objects for IP ranges and ASNs not allocated or assigned by the NCC are fully supported (see the FAQ at http://www.ripe.net/data-tools/db/faq/faq-db, Q: How to create a route object when the matching IP range is not allocated or assigned from the RIPE NCC?) etc. Someone with IP space from Afrinic and an ASN from LACNIC is allowed to create a route object in the RIPE database. But now suddenly an exception must be made for legacy resources? Besides, I think that what you suggest will really create a lot of work for the database team of the NCC. I can't even imagine the mess of business logic necessary to implement what you suggest. Being a paying NCC member myself I would be very strongly against the NCC putting any effort/money into such complications. Sander
On 02/11/2013 23:07, Sander Steffann wrote:
I personally find this a bit petty. You seem to have a very different idea about the RIPE database than I have. The RIPE database is a service to the *community*, not only the NCC members.
I'm genuinely sorry that you find this petty. It would certainly be petty if this were a temporary arrangement or if it were something which only applied to a tiny number of organisations, but it's neither. This part of the policy will apply as a permanent arrangement for what will probably be a sizeable proportion of the existing organisation base which receives registry services from the RIPE NCC (obviously excluding the responsible legacy holders who opt for sections 2.1 - 2.4). From any reasonable viewpoint, it cannot be written off as petty.
And the database != the registry.
Indeed - and to be more precise, under the terms of my suggestion, the data would still be maintained in the registry and the holders can make modifications as required, but if they decline to pay for services, then they wouldn't get IRRDB service or the reverse DNS service - which are slightly separate functions to the address registry.
But now suddenly an exception must be made for legacy resources?
Third parties can still register data in the ripedb, but they lose out on stuff which makes it worthwhile, e.g. object grandfathering (giving good quality object security). The legacy objects will be equivalently authorised to native RIPE NCC allocated objects, so it is a subtle but important fallacy to suggest that an exception would be made for LRHs when in fact it's the opposite that's true in a difference sense: third party objects don't get reverse DNS service and don't have an authenticated IRRDB service.
Besides, I think that what you suggest will really create a lot of work for the database team of the NCC. I can't even imagine the mess of business logic necessary to implement what you suggest.
I'll leave it up to the RIPE NCC to comment on this, but the hooks exist already (mnt-domains: and mnt-routes:) and unless my understanding of the ripedb is mistaken, I don't see that it would be a huge amount of work. Sander, it is not unreasonable to expect that organisations which register data in the RIPE database should contribute towards the running costs of the service they use. There is nothing unfair about this and it's not petty. It is a reasonable and fair approach to creating a permanent, long term solution for dealing with the requirements of the legacy resource holder community and the internet community in general. As a separate issue, there is also no incentive whatsoever in 2012-07 for legacy resource holders to engage with the RIPE NCC. When the NCC come knocking on LRH doors under the current terms of 2012-07, they will present two options: 1. sign contracts, pay money, service as usual 2. don't bother signing anything, don't bother paying, service as usual Realistically, most LRHs are not going to bother engaging with the RIPE NCC under the current terms of this proposal because they do not benefit in any meaningful way from doing so. This and the lack of quid-pro-quo are the two main reasons why this proposal is critically flawed and why it should not become RIPE community policy in its current form. Nick
At 01:09 03/11/2013 +0000, Nick Hilliard wrote:
This and the lack of quid-pro-quo are the two main reasons why this proposal is critically flawed and why it should not become RIPE community policy in its current form.
Nick
About 15 people stated their support for 2012-07 in this forum so for me as one of the authors I see this as consensus. Consensus does not mean everyone has to agree - just that most people need to agree. As I see it, most people agree. -Hank
On Sun, Nov 3, 2013 at 6:38 AM, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
At 01:09 03/11/2013 +0000, Nick Hilliard wrote:
This and the lack of quid-pro-quo are the two main reasons why this proposal is critically flawed and why it should not become RIPE community policy in its current form.
Nick
About 15 people stated their support for 2012-07 in this forum so for me as one of the authors I see this as consensus. Consensus does not mean everyone has to agree - just that most people need to agree. As I see it, most people agree.
I think your view on Consensus are a bit of with what alot of us other think, please go read https://datatracker.ietf.org/doc/draft-resnick-on-consensus/ Or a shorter answer, it's not about the number, it is about getting people to agree it is a doable solution even when they don't agree on all. Their biggest objections need to be addressed, and discussed. -- Roger Jorgensen | ROJO9-RIPE rogerj@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no
Hi, On Sun, Nov 03, 2013 at 01:18:03PM +0100, Roger Jørgensen wrote:
I think your view on Consensus are a bit of with what alot of us other think, please go read https://datatracker.ietf.org/doc/draft-resnick-on-consensus/
Or a shorter answer, it's not about the number, it is about getting people to agree it is a doable solution even when they don't agree on all. Their biggest objections need to be addressed, and discussed.
I think Sander did that: address and discuss the objection Nick raised. From what I saw in the discussion, the main thing seems to be that Nick is assuming most LRHs are free-riders, while the authors of the proposal assume that there is interest among the LRHs to strengthen their ties to the NCC and pay a reasonable fee for that, except for a small subset who would not do that. We can't know who is right - without asking "most" of the LRHs, which I consider unreasonable - so in the end the chairs will have to decide whether they share the view that this is a too high risk, or whether they see it as one loud voice sticking to unreasonable objection - and that is fully in line with the draft you reference :-) Gert Doering -- just a LIR -- 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 (0)89/32356-444 USt-IdNr.: DE813185279
On 03/11/2013 13:06, Gert Doering wrote:
From what I saw in the discussion, the main thing seems to be that Nick is assuming most LRHs are free-riders
The bias expressed in the term "free-riders" is not really appropriate for this discussion. When presented with multiple options which provide substantially the same outcome, most organisations will take the simplest and easiest option. In this case, this option will be not to sign or pay anything. This will not represent a weakness on the part of the LRHs who decline to sign or pay. It will simply be an acknowledgement that of all the options presented in the proposal, it will be by far the easiest option to take and the end result for the resource holder will be almost exactly the same. Nick
Hi,
This and the lack of quid-pro-quo are the two main reasons why this proposal is critically flawed and why it should not become RIPE community policy in its current form.
We're going in circles here. I already expressed why I disagree with you on these points. Let's just agree to disagree here. Sander
Hi Nick, On 2 Nov 2013, at 19:49, Nick Hilliard <nick@netability.ie> wrote:
The root of my objection is that there is no quid pro quo, and this proposal formalises this situation in such a way that it will not be possible to change it in future. Because of the way that the PDP works, any future attempt to change this situation will be shot down.
If that's so, I'm not sure how we can expect any current attempt to change the situation to be any more successful. So maybe we should just give up and accept the status quo? :-) We've both been in the situation a number of times where we want a proposal to go further than it actually does. I hear what you say, but nonetheless, 2.6 is the status quo. 2.1-2.5 (modulo Tore's comments) improve the situation. You're asking for 2.1-2.5 to be stopped unless and until there is consensus around removing existing services to LRHs, specifically because you think it will be difficult to get consensus around this. Traditionally in this scenario, one splits it out and forms a separate policy proposal. All the best, Dave -- Dave Wilson ---- Project Manager web: www.heanet.ie HEAnet, 5 George's Dock, Dub 1 tel: +353-1-660-9040 Registered in Ireland, no 275301 fax: +353-1-660 3666 HEAnet National Conference 2013 -- http://www.heanet.ie/conferences/2013/
Hello, It looks like there are only a couple of days before the end of last call on this proposal. There are still several issues which I've brought up throughout the proposal which haven't been answered, even though some of them have been brought up several times on the mailing list. I.e. none of them are new, but none of them has been dealt with either. Excluding my concerns with section 2.6 where I respect the community consensus but still strongly disagree with, these issues include from my email of 2013-11-01:
Serious issues: Section 3.0 needs to include a term in the contract to state that the services provided by the RIPE NCC to the legacy resource holder are defined by RIPE community policy and may be amended from time to time, according to ripe community policy. [...] Section 2.4 is redundant. We have a well established precedent under the terms of 2007-01 for engaging with sponsoring LIRs and this seems to work well in practice. Creating this policy option merely adds cost to the RIPE NCC's bottom line for no gain.
Nits:
Section 3.0: "a statement that the RIPE NCC is not entitled to deregister the resources for whatever purpose unless so instructed by the resource holder". This statement is advisory only and it needs to be made clear that the sponsoring LIR does not have power to make a legally binding statement of this form. This actually applies to all four statements in section 3.0.
Nick
Hi Nick, We've asked the RIPE NCC for some clarity on your comments regarding section 3.0 in the policy proposal, please see Athina's reply below: === There are two elements we would like to clarify with this regards: - Who defines the services provided by the RIPE NCC to legacy resource holders - The inclusion of possible amendments to the NCC services provided to legacy resources as a term of the contract. 1. Who defines the services provided by the RIPE NCC to legacy resource holders The policy proposal (section 1.1) outlines the registration services generally provided by the RIPE NCC: "Registration Services - Services provided by the RIPE NCC in its capacity as a Regional Internet Registry, including the following and such additional services as may be identified from time to time as registry services: - Maintenance of data relating to Internet Resources by the NCC in their Internet Resource registry; - Access to these data for update by or on behalf of the respective holder; - Public availability of registration data; - Certification of these data; and - Delegation of reverse DNS to the registered DNS servers." Furthermore in section 4.0 the proposal clarifies the services available to legacy holders, depending on the type of contractual relationship a legacy holder wants to have with the RIPE NCC. About future RIPE NCC services, whether they will be considered as Registration services available to legacy resources, we believe that this should be a decision to be made not just by the RIPE community but by the RIPE NCC membership as well, because the membership is the one deciding on the RIPE NCC services in general. This view is also reflected in the RIPE NCC’s impact analysis (section A): “This definition gives a non-exclusive list of services. Other services, both current and future, may also be considered Registration Services. This proposal does not specify the process according to which a service (other than those listed) is identified as Registration Services. Therefore, the RIPE NCC will make this decision after consultation with the membership and RIPE Community.” 2. The inclusion of possible amendments to the NCC services provided to legacy resources as a term of the contract. Section 3.0 of the proposal requires that the contractual agreement includes: - “the obligation for both parties to comply with this policy and with other RIPE policies which relate to Legacy Internet Resources.” - "specification of the service or services offered in respect of each resource identified". Accordingly: - legacy holders will have to agree that they comply with the RIPE policies anyway - the proposal requires that each legacy holder specifies the services they want for their resources. So not every registration services available to legacy resources will be automatically included to their contract unless they specifically ask for it. Therefore we believe that an addition of a term that includes automatically new services to the contract with legacy holders would contradict the other term of the proposal (about the specification of the services in respect of each resource identified). === I hope this addresses the concerns you raised below. Best regards, Bijal On 15 Dec 2013, at 14:31, Nick Hilliard <nick@netability.ie> wrote:
Hello,
It looks like there are only a couple of days before the end of last call on this proposal. There are still several issues which I've brought up throughout the proposal which haven't been answered, even though some of them have been brought up several times on the mailing list.
I.e. none of them are new, but none of them has been dealt with either.
Excluding my concerns with section 2.6 where I respect the community consensus but still strongly disagree with, these issues include from my email of 2013-11-01:
Serious issues: Section 3.0 needs to include a term in the contract to state that the services provided by the RIPE NCC to the legacy resource holder are defined by RIPE community policy and may be amended from time to time, according to ripe community policy. [...] Section 2.4 is redundant. We have a well established precedent under the terms of 2007-01 for engaging with sponsoring LIRs and this seems to work well in practice. Creating this policy option merely adds cost to the RIPE NCC's bottom line for no gain.
Nits:
Section 3.0: "a statement that the RIPE NCC is not entitled to deregister the resources for whatever purpose unless so instructed by the resource holder". This statement is advisory only and it needs to be made clear that the sponsoring LIR does not have power to make a legally binding statement of this form. This actually applies to all four statements in section 3.0.
Nick
On 23/12/2013 11:29, Bijal Sanghani wrote:
We've asked the RIPE NCC for some clarity on your comments regarding section 3.0 in the policy proposal, please see Athina's reply below: [...] “This definition gives a non-exclusive list of services. Other services, both current and future, may also be considered Registration Services. This proposal does not specify the process according to which a service (other than those listed) is identified as Registration Services. Therefore, the RIPE NCC will make this decision after consultation with the membership and RIPE Community.” [...] Therefore we believe that an addition of a term that includes automatically new services to the contract with legacy holders would contradict the other term of the proposal (about the specification of the services in respect of each resource identified).
ok, i see the reasoning behind this and withdraw my concerns about sections 3.0 and 2.4. Nick
Dear All, I am very happy to say that consensus has been reached for Policy Proposal 2012-07. Marco will send the official accepted message shortly. Best regards, Bijal On 23 Dec 2013, at 12:07, Nick Hilliard <nick@netability.ie> wrote:
On 23/12/2013 11:29, Bijal Sanghani wrote:
We've asked the RIPE NCC for some clarity on your comments regarding section 3.0 in the policy proposal, please see Athina's reply below: [...] “This definition gives a non-exclusive list of services. Other services, both current and future, may also be considered Registration Services. This proposal does not specify the process according to which a service (other than those listed) is identified as Registration Services. Therefore, the RIPE NCC will make this decision after consultation with the membership and RIPE Community.” [...] Therefore we believe that an addition of a term that includes automatically new services to the contract with legacy holders would contradict the other term of the proposal (about the specification of the services in respect of each resource identified).
ok, i see the reasoning behind this and withdraw my concerns about sections 3.0 and 2.4.
Nick
participants (7)
-
Bijal Sanghani -
Dave Wilson -
Gert Doering -
Hank Nussbacher -
Nick Hilliard -
Roger Jørgensen -
Sander Steffann