From nick at netability.ie Fri Nov 1 17:51:16 2013 From: nick at netability.ie (Nick Hilliard) Date: Fri, 01 Nov 2013 16:51:16 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 Message-ID: <5273DC04.9090004@netability.ie> 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 From sander at steffann.nl Fri Nov 1 18:27:37 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 1 Nov 2013 18:27:37 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5273DC04.9090004@netability.ie> References: <5273DC04.9090004@netability.ie> Message-ID: 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 From nick at netability.ie Fri Nov 1 18:38:13 2013 From: nick at netability.ie (Nick Hilliard) Date: Fri, 01 Nov 2013 17:38:13 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: References: <5273DC04.9090004@netability.ie> Message-ID: <5273E705.4040801@netability.ie> 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 From nick at netability.ie Fri Nov 1 18:42:56 2013 From: nick at netability.ie (Nick Hilliard) Date: Fri, 01 Nov 2013 17:42:56 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: References: <5273DC04.9090004@netability.ie> Message-ID: <5273E820.8060905@netability.ie> 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 From sander at steffann.nl Fri Nov 1 18:55:38 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 1 Nov 2013 18:55:38 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5273E705.4040801@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E705.4040801@netability.ie> Message-ID: <2D1004E8-6C6F-469C-8C0D-F67E1FADD558@steffann.nl> 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 From nick at netability.ie Fri Nov 1 18:59:46 2013 From: nick at netability.ie (Nick Hilliard) Date: Fri, 01 Nov 2013 17:59:46 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <2D1004E8-6C6F-469C-8C0D-F67E1FADD558@steffann.nl> References: <5273DC04.9090004@netability.ie> <5273E705.4040801@netability.ie> <2D1004E8-6C6F-469C-8C0D-F67E1FADD558@steffann.nl> Message-ID: <5273EC12.6050907@netability.ie> 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 From sander at steffann.nl Fri Nov 1 19:00:11 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 1 Nov 2013 19:00:11 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5273E820.8060905@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> Message-ID: <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> 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 From sander at steffann.nl Fri Nov 1 19:00:59 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 1 Nov 2013 19:00:59 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5273EC12.6050907@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E705.4040801@netability.ie> <2D1004E8-6C6F-469C-8C0D-F67E1FADD558@steffann.nl> <5273EC12.6050907@netability.ie> Message-ID: 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 From nick at netability.ie Fri Nov 1 19:06:10 2013 From: nick at netability.ie (Nick Hilliard) Date: Fri, 01 Nov 2013 18:06:10 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> Message-ID: <5273ED92.2050205@netability.ie> 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 From sander at steffann.nl Fri Nov 1 19:16:04 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 1 Nov 2013 19:16:04 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5273ED92.2050205@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> Message-ID: <88EDF3EA-D922-43C4-B7BA-328DC9AF69BD@steffann.nl> Hi, Op 1 nov. 2013, om 19:06 heeft Nick Hilliard 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 From sander at steffann.nl Fri Nov 1 19:50:02 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 1 Nov 2013 19:50:02 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5273ED92.2050205@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> Message-ID: <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> 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 From nick at netability.ie Fri Nov 1 22:15:56 2013 From: nick at netability.ie (Nick Hilliard) Date: Fri, 01 Nov 2013 21:15:56 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> Message-ID: <52741A0C.6040904@netability.ie> 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 From sander at steffann.nl Fri Nov 1 22:49:07 2013 From: sander at steffann.nl (Sander Steffann) Date: Fri, 1 Nov 2013 22:49:07 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <52741A0C.6040904@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> Message-ID: <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> Hi Nick, Op 1 nov. 2013, om 22:15 heeft Nick Hilliard 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 From nick at netability.ie Sat Nov 2 20:49:04 2013 From: nick at netability.ie (Nick Hilliard) Date: Sat, 02 Nov 2013 19:49:04 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> Message-ID: <52755730.9000909@netability.ie> 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 From sander at steffann.nl Sun Nov 3 00:07:18 2013 From: sander at steffann.nl (Sander Steffann) Date: Sun, 3 Nov 2013 00:07:18 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <52755730.9000909@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> <52755730.9000909@netability.ie> Message-ID: Hi Nick, Op 2 nov. 2013, om 20:49 heeft Nick Hilliard 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 From nick at netability.ie Sun Nov 3 02:09:20 2013 From: nick at netability.ie (Nick Hilliard) Date: Sun, 03 Nov 2013 01:09:20 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> <52755730.9000909@netability.ie> Message-ID: <5275A240.6090001@netability.ie> 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 From hank at efes.iucc.ac.il Sun Nov 3 06:38:51 2013 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Sun, 03 Nov 2013 07:38:51 +0200 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5275A240.6090001@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> <52755730.9000909@netability.ie> Message-ID: <5.1.1.6.2.20131103073521.01edfee0@efes.iucc.ac.il> 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 From tore at fud.no Sun Nov 3 11:00:32 2013 From: tore at fud.no (Tore Anderson) Date: Sun, 03 Nov 2013 11:00:32 +0100 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: References: Message-ID: <52761EC0.1000507@fud.no> Hi WG, Clarifying the "legal" status of the legacy holders without taking away any of their pre-existing rights is an improvement over the current undefined and ad-hoc practices, and I think it will likely cause a positive incentive for these organisations to actively participate in the community and to keep their registry entries accurate, which is a benefit not only to the legacy holders themselves and the RIPE NCC and its membership, but the entire internet and routing communities as a whole. I believe 2012-07 accomplishes the above while striking a decent balance between the interests of all involved parties. That said, I do not see the purpose of section 2.4 ?Option to engage directly with the RIPE NCC?. Section 2.2 ?Option to become a RIPE NCC member? seems to me to accomplish the same thing, only without requiring a new contract class to be established. Having only two options (full member, or registered via a sponsoring LIR) would maintain consistency with current operational practices regarding PI assignments, and would reduce the operational impact of this policy as existing business structures and practices already instated for PI holders could be re-used for legacy holders. For this reason I will likely vote against the creation of such a special contract option at the AGM. Nor do I see the purpose of section 2.5 ?When there are obstacles for 2.1/2.2/2.3/2.4?, as section 2.6 ?No relationship? seems to cover this case. Perhaps it's only my imagination being limited, but the only likely "obstacle" I can envision here is that the resource holder cannot produce adequate proof of ownership, and in that case section 2.6 ("the status quo, but no more") seems like the the most reasonable way to proceed. I'd certainly be opposed to the RIPE NCC unilaterally having to "confirm" such unproved ownership, e.g., by providing certification services, in the same way as if ownership was properly proven according to the provisions in sections 2.1 through 2.4. That said, the Impact Analysis seems to me to say that section 2.5 would be implemented in pretty much the same way as section 2.6, so I suppose there is no real cause for concern here even though the policy text itself makes me somewhat uneasy. So in summary, while I would have preferred to see sections 2.4 and 2.5 be removed completely, I consider the proposal as a whole to provide a net benefit. Therefore: Support. Tore (a RIPE NCC member who holds no legacy resources) From rogerj at gmail.com Sun Nov 3 13:18:03 2013 From: rogerj at gmail.com (=?ISO-8859-1?Q?Roger_J=F8rgensen?=) Date: Sun, 3 Nov 2013 13:18:03 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5.1.1.6.2.20131103073521.01edfee0@efes.iucc.ac.il> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> <52755730.9000909@netability.ie> <5275A240.6090001@netability.ie> <5.1.1.6.2.20131103073521.01edfee0@efes.iucc.ac.il> Message-ID: On Sun, Nov 3, 2013 at 6:38 AM, Hank Nussbacher 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 at gmail.com | - IPv6 is The Key! http://www.jorgensen.no | roger at jorgensen.no From sander at steffann.nl Sun Nov 3 13:58:00 2013 From: sander at steffann.nl (Sander Steffann) Date: Sun, 3 Nov 2013 13:58:00 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <5275A240.6090001@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> <52755730.9000909@netability.ie> <5275A240.6090001@netability.ie> Message-ID: <3DE8A363-289F-4373-AB4A-0D457C4C7BFD@steffann.nl> 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 From gert at space.net Sun Nov 3 14:06:36 2013 From: gert at space.net (Gert Doering) Date: Sun, 3 Nov 2013 14:06:36 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: References: <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> <52755730.9000909@netability.ie> <5275A240.6090001@netability.ie> <5.1.1.6.2.20131103073521.01edfee0@efes.iucc.ac.il> Message-ID: <20131103130636.GQ50205@Space.Net> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From jako.andras at eik.bme.hu Sun Nov 3 16:05:18 2013 From: jako.andras at eik.bme.hu (=?utf-8?B?SsOBS8OTIEFuZHLDoXM=?=) Date: Sun, 3 Nov 2013 16:05:18 +0100 Subject: [ncc-services-wg] 2012-07 Services to Legacy Internet Resource Holders Message-ID: <20131103150517.GB486@eik.bme.hu> Dear Colleagues, I support proposal 2012-07's adoption as a RIPE policy. Thanks for the work of the authors! Andr?s From nick at netability.ie Sun Nov 3 23:24:36 2013 From: nick at netability.ie (Nick Hilliard) Date: Sun, 03 Nov 2013 22:24:36 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <20131103130636.GQ50205@Space.Net> References: <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> <52755730.9000909@netability.ie> <5275A240.6090001@netability.ie> <5.1.1.6.2.20131103073521.01edfee0@efes.iucc.ac.il> <20131103130636.GQ50205@Space.Net> Message-ID: <5276CD24.9060309@netability.ie> 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 From jassadi1971 at gmail.com Sat Nov 2 06:05:35 2013 From: jassadi1971 at gmail.com (Jahangir Asadi) Date: Sat, 2 Nov 2013 08:35:35 +0330 Subject: [ncc-services-wg] Asking Used IPs Monitoring Methods Message-ID: Dear Sir or Madam I have some customers who I have dedicated high band width a wide ranges of IPv4 addresses to them. Because of lack of IPv4, I would like to see that how many IPs they are using. It would be grateful if you tell me how can I do this and what soft ware I have to use to monitor the used IPs. I would like to thank you in advance and I am looking forward to hearing from you soon. Regards. Jahangir Asadi Network Manager of Padidar Information Technology (Your LIR Member and the owner of AS198357) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Woeber at CC.UniVie.ac.at Mon Nov 4 10:51:55 2013 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Mon, 04 Nov 2013 10:51:55 +0100 Subject: [ncc-services-wg] is IPv4 address solicitation compatible with DB AUP or spam? Message-ID: <52776E3B.9080105@CC.UniVie.ac.at> Well, "it" seems to take off, we keep getting solicitations for IPv4 address transfer to (presumably) all contact addresses linked to in our resource objects. Some of these messages are from an idividual who seemingly is advertising for at least 2 different brokers. So here's my question: is that sort of spamming compatible with the DB-AUP? How about some sort of opt-out tag, telling everyone and her dog: "no, don't bother to ask, we won't give you our addresses"? Thanks, Wilfried From dave.wilson at heanet.ie Mon Nov 4 11:09:44 2013 From: dave.wilson at heanet.ie (Dave Wilson) Date: Mon, 4 Nov 2013 10:09:44 +0000 Subject: [ncc-services-wg] comments on proposal 2012-07 In-Reply-To: <52755730.9000909@netability.ie> References: <5273DC04.9090004@netability.ie> <5273E820.8060905@netability.ie> <15C89857-62B4-486C-BA01-A3FBE9318FC0@steffann.nl> <5273ED92.2050205@netability.ie> <39ACBE22-E8F8-4543-86C8-DF4335B9DA0E@steffann.nl> <52741A0C.6040904@netability.ie> <37710976-FC4D-492F-8CC0-60A702111ED1@steffann.nl> <52755730.9000909@netability.ie> Message-ID: <18BEE031-626F-4DBD-AF6A-1367EB5BF48A@heanet.ie> Hi Nick, On 2 Nov 2013, at 19:49, Nick Hilliard 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/ From tore at fud.no Mon Nov 4 13:59:14 2013 From: tore at fud.no (Tore Anderson) Date: Mon, 04 Nov 2013 13:59:14 +0100 Subject: [ncc-services-wg] 2012-07 New Draft Document and Impact Analysis Published (RIPE NCC Services to Legacy Internet Resource Holders) In-Reply-To: <52761EC0.1000507@fud.no> References: <52761EC0.1000507@fud.no> Message-ID: <52779A22.9040709@fud.no> * Tore Anderson > So in summary, while I would have preferred to see sections 2.4 and 2.5 > be removed completely, I consider the proposal as a whole to provide a > net benefit. Therefore: Support. Replying to myself because I forgot to mention something yesterday: I fail to see the point in having sections 2.1 and 2.2 as two separate options. They describe essentially the same option - where the legacy holder is (in the end) a RIPE NCC member. In my opinion it goes without saying that if the legacy holder opts for this option, then a) if he is not already a RIPE NCC member, then he would need to first join; or conversely, b) if he is already a RIPE NCC member, he would not need to (re-)join. Describing this as a single option would IMHO have made the policy more concise and easily understood. But fixing this would just be the icing on the cake - I still support the adoption of the proposal as-is (?perfect is the enemy of good?). This particular imperfection, and the other things I mentioned yesterday, can be cleaned up later if someone cares enough to do so. Tore From gert at space.net Mon Nov 4 14:47:01 2013 From: gert at space.net (Gert Doering) Date: Mon, 4 Nov 2013 14:47:01 +0100 Subject: [ncc-services-wg] is IPv4 address solicitation compatible with DB AUP or spam? In-Reply-To: <52776E3B.9080105@CC.UniVie.ac.at> References: <52776E3B.9080105@CC.UniVie.ac.at> Message-ID: <20131104134701.GD81676@Space.Net> Hi, On Mon, Nov 04, 2013 at 10:51:55AM +0100, Wilfried Woeber wrote: > So here's my question: is that sort of spamming compatible with the DB-AUP? > > How about some sort of opt-out tag, > telling everyone and her dog: "no, don't bother to ask, we won't give you our addresses"? I have always considered the e-mail addresses in the RIPE database to be completely incompatible with "establishing contact for purely commercial purposes", to phrase it this way. And I do not want opt-out of this - if I were willing to sell my address space, I'd use the NCC listing service to advertise that. (And these guys are spammers anyway, they do not want to have the space properly transfered and registered to them, just lease it for a few more spam runs, get it black listed, move elsewhere) 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 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: From gilles.massen at restena.lu Wed Nov 6 10:02:45 2013 From: gilles.massen at restena.lu (Gilles Massen) Date: Wed, 06 Nov 2013 10:02:45 +0100 Subject: [ncc-services-wg] 2012-07 Services to Legacy Internet Resource Holders Message-ID: <527A05B5.4090601@restena.lu> Dear all, I support proposal 2012-07's adoption as policy. It seems fairly balanced and should provide an option for every LRH without putting unacceptable load on the RIPE NCC (or its members). Thanks to the authors. Best regards, Gilles -- Fondation RESTENA - DNS-LU 6, rue Coudenhove-Kalergi L-1359 Luxembourg tel: (+352) 424409 fax: (+352) 422473 From denis at ripe.net Wed Nov 6 15:02:51 2013 From: denis at ripe.net (Denis Walker) Date: Wed, 06 Nov 2013 15:02:51 +0100 Subject: [ncc-services-wg] Fwd: [db-wg] RIPE Database Release 1.70 Available In-Reply-To: <5271310F.4000707@ripe.net> References: <5271310F.4000707@ripe.net> Message-ID: <527A4C0B.6010806@ripe.net> Dear Colleagues, Please note that release 1.70 will be deployed to the production servers on Thursday 14th November 2013 and not on 12th November as shown in the message below. Regards, Denis Walker Business Analyst RIPE NCC Database Team -------- Original Message -------- Subject: [db-wg] RIPE Database Release 1.70 Available Date: Wed, 30 Oct 2013 17:17:19 +0100 From: Denis Walker Organization: RIPE NCC To: Database WG , NCC Services WG , RIPE Routing WG Dear colleagues, The RIPE NCC is pleased to announce that we will deploy a new release of the RIPE Database to the TEST Database environment on Thursday, 31 October 2013. The release is scheduled for production deployment on Thursday, 12 November 2013. Detailed information about the new release, including dates and information about the changes, can be found at: https://www.ripe.net/data-tools/db/release-notes/ripe-database-release-1.70 Of special note in this release is the inclusion of "pending route authentication". This is an alternative and simplified way of authorising route object creation. Two separate updates for a single route/route6 object are treated as one create request. This has no impact on users who still submit a complete route object with all authorisations included. If you have any questions or comments, we look forward to hearing them. Regards, Denis Walker Business Analyst RIPE NCC Database Team From andrew at ripe.net Wed Nov 6 17:31:08 2013 From: andrew at ripe.net (Andrew de la Haye) Date: Wed, 6 Nov 2013 17:31:08 +0100 Subject: [ncc-services-wg] comments on proposal 2012-07 Message-ID: <64AA5B0E-A846-4949-A7F0-BED0D8302FB0@ripe.net> Dear colleagues, In this email thread, the RIPE NCC was asked to provide a cost estimate for the implementation of policy proposal 2012-07. The estimated total costs for implementation of this proposal are between 100 kEUR and 350 kEUR, spread out over several years. These costs include things such as setting up the appropriate fields in the RIPE Database, internal software development, and administrative overhead - including creating the appropriate legal contracts. Whether the actual costs are closer to the upper or lower end of this estimate will be determined by how many legacy holders decide to enter into a contractual relationship with the RIPE NCC or a sponsoring LIR. The smaller estimate reflects 25% of legacy holders, while the larger estimate represents 100% of legacy holders deciding to enter into a contractual relationship. Note also that these costs have not been offset against the additional income that would likely come as the result of some legacy holders deciding to become RIPE NCC members. There are obvious parallels between implementation of this policy and the implementation of policy proposal 2007-01, "Direct Internet Resource Assignments to End Users from the RIPE NCC". However, the overall number of organisations and Internet number resources related to this proposal is lower. Also, it is optional, rather than mandatory, for organisations to enter into a contractual relationship with the RIPE NCC. For this reason, the operational and financial impact of implementation will be considerably lower. Kind regards Andrew de la Haye Chief Operations Officer RIPE NCC From denis at ripe.net Tue Nov 12 15:59:27 2013 From: denis at ripe.net (Denis Walker) Date: Tue, 12 Nov 2013 15:59:27 +0100 Subject: [ncc-services-wg] RIPE Database Release 1.70 Message-ID: <5282424F.10404@ripe.net> Dear colleagues, The new release 1.70 of the RIPE Database was deployed to the TEST Database environment on Thursday, 31 October 2013 and is now ready to be deployed to the production database. The deployment will commence at 20:00 (UTC+1) on Thursday, 14 November 2013 and may take up to three hours to complete. During this time, updates will not be available. Any email updates submitted during this period will be queued. Updates by any other means will return an error message. Queries will not be affected during this deployment. The reason for the outage is an operational clean-up that the RIPE NCC has to do occasionally on the RIPE Database. Some long-since deprecated objects and attributes will be removed from the SQL table structure. This clean-up will not cause any visible change to users. The clean-up was done on the TEST Database during the deployment of 1.70 in October. Regards Denis Walker Business Analyst RIPE NCC Database Team From alexb at ripe.net Mon Nov 18 08:44:03 2013 From: alexb at ripe.net (Alex Band) Date: Mon, 18 Nov 2013 08:44:03 +0100 Subject: [ncc-services-wg] Follow up on implementation of Resource Certification (RPKI) for PI End User Resources Message-ID: <68D7B63F-B5BE-49D8-A96A-39E05D7FBEB0@ripe.net> Dear colleagues, Over the last few weeks, we have been consulting the RIPE community on the practical implementation of providing Resource Certification (RPKI) for Provider Independent (PI) End Users. In about two weeks, we plan to start with the implementation and, based on the feedback that you have provided, we would like to offer the following two solutions: 1. A management interface for sponsoring LIRs in the LIR Portal Sponsoring LIRs will be able to issue access credentials for the RPKI Management interface to either themselves if they manage ROAs on behalf of the PI End User, or directly to the PI End User if they have requested to set up and maintain ROAs. 2. A form on the RIPE NCC website, allowing PI End Users to request access directly from the RIPE NCC PI End Users will be able to log in with their RIPE NCC Access account, enter the resources they would like a certificate for and authenticate against the INETNUM database object to prove they have authoritative control over the address space. If you have any feedback, please do not hesitate to respond to this message. Kind regards, Alex Band Product Manager RIPE NCC P.S. The RIPE NCC has explained the implementation options and associated cost at the following locations: http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002145.html http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002149.html http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002252.html http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-March/002256.html http://www.ripe.net/ripe/mail/archives/ncc-services-wg/2013-October/002587.html From bijal.sanghani at euro-ix.net Mon Nov 18 15:03:45 2013 From: bijal.sanghani at euro-ix.net (Bijal Sanghani) Date: Mon, 18 Nov 2013 14:03:45 +0000 Subject: [ncc-services-wg] 2012-07 RIPE NCC Services to Legacy Internet Resource Holders - moving to last call Message-ID: <04E2CBC9-5F00-4C07-B38E-A074DED1CD9B@euro-ix.net> Greetings colleagues, The NCC Services working group co-chairs have concluded that policy proposal 2012-07 - RIPE NCC Services to Legacy Internet Resource Holders will now move to last call, we believe consensus has been reached. During the last call phase the community still has an opportunity to present any sound objections that may have been missed in the previous two phases. Marco will send a mail shortly with full details of the last call shortly. Best regards, Kurtis and Bijal NCC Services WG co-chairs -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Mon Nov 18 15:09:11 2013 From: mschmidt at ripe.net (Marco Schmidt) Date: Mon, 18 Nov 2013 15:09:11 +0100 Subject: [ncc-services-wg] 2012-07 Last Call for Comments (RIPE NCC Services to Legacy Internet Resource Holders) Message-ID: Dear colleagues, The proposal described in 2012-07, RIPE NCC Services to Legacy Internet Resource Holders, is now in its Concluding Phase. The RIPE NCC Services Working Group co-Chairs have declared that consensus for the proposal has been reached and it will now move to Last Call. As per the RIPE Policy Development Process (PDP), the purpose of these coming four weeks of Last Call is to give the community the opportunity to present well-justified objections in case anyone missed the previous two phases and want to oppose the proposal. Any objection must be made by 17 December 2013 and must be supported by an explanation. If no substantive objections are raised by the end of Last Call, the proposal will complete the PDP and will be evaluated by the co-Chairs of all RIPE Working Groups for consensus. You can find the full proposal at: https://www.ripe.net/ripe/policies/proposals/2012-07 Please e-mail any final comments about this proposal to ncc-services-wg at ripe.net before 17 December 2013. Regards Marco Schmidt Policy Development Office RIPE NCC From training at ripe.net Tue Nov 19 09:41:26 2013 From: training at ripe.net (Training Team) Date: Tue, 19 Nov 2013 09:41:26 +0100 Subject: [ncc-services-wg] [training] RIPE NCC Training Courses January-March 2014 Message-ID: <528B2436.3060909@ripe.net> Dear Colleagues, Our training team travels the RIPE NCC service region to deliver training courses to our members without any additional cost. Over the next few months, we'll be in Lisbon, Frankfurt, Busto Arsizio, Manamah, St. Petersburg, Tallinn, London, Warsaw, Copenhagen, Amsterdam, Bucharest. Visit the following page to register and to check which training courses we are giving in your area: https://lirportal.ripe.net/training/courses The RIPE NCC delivers the following training courses: - LIR Training Course - RIPE Database Training Course - IPv6 for LIRs Training Course - Routing Security Training Course For more information visit: http://www.ripe.net/lir-services/training/courses With kind regards, Rumy Spratley-Kanis Training Services Manager -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexb at ripe.net Mon Nov 25 13:49:54 2013 From: alexb at ripe.net (Alex Band) Date: Mon, 25 Nov 2013 13:49:54 +0100 Subject: [ncc-services-wg] RPKI Validator 2.13 released Message-ID: Hello everyone, We just released RPKI Validator 2.13 and I would just like to highlight a couple of important improvements and fixes. 1. Single, unified configuration file We recently received a request to allow overriding the default paths of the application to allow Debian packaging. This meant we ended up with so many startup flags and environment variables that we decided to put every user configurable option together in one single file. You can choose your own name and path for the config file, to allow for easy updating without overwriting your preferences. 2. Application health and trust anchor monitoring Quite some users have asked us to implement monitoring, so they can keep an eye on whether the application itself is running properly and if the RPKI repositories are available and serving data. Application health monitoring currently only checks if the rsync binary can be found and executed. For Trust Anchor monitoring we built a dedicated page. For example: http://localcert.ripe.net:8088/trust-anchor-monitor/44a4f26e67 Both are a basic, initial implementations. We?re actively looking for feedback on which checks you would like to see and how you would like to be able to implement them in your monitoring setups. 3. Deep linking You can specify an AS Number or prefix in the URL of the ROA and BGP Preview pages to get direct, bookmark-able access to information. For example: - http://localcert.ripe.net:8088/roas?q=2001:7fb:fe01::/48 - http://localcert.ripe.net:8088/bgp-preview?q=AS12654 4. Bug and conformance fixes At IETF88 in Vancouver we did some rigorous testing with other implementors to see how the application handles malformed objects. A couple of bugs and other anomalies came to light that have been fixed in this version. You can download RPKI Validator 2.13 here: https://www.ripe.net/lir-services/resource-management/certification/tools-and-resources We recommend that you update to this release. As always, we look forward to your feedback. Kind regards, Alex Band Product Manager RIPE NCC From nat at nuqe.net Tue Nov 26 16:00:09 2013 From: nat at nuqe.net (Nat Morris) Date: Tue, 26 Nov 2013 15:00:09 +0000 Subject: [ncc-services-wg] Follow up on implementation of Resource Certification (RPKI) for PI End User Resources In-Reply-To: <68D7B63F-B5BE-49D8-A96A-39E05D7FBEB0@ripe.net> References: <68D7B63F-B5BE-49D8-A96A-39E05D7FBEB0@ripe.net> Message-ID: On 18 November 2013 07:44, Alex Band wrote: > Dear colleagues, > > Over the last few weeks, we have been consulting the RIPE community on the practical implementation of providing Resource Certification (RPKI) for Provider Independent (PI) End Users. In about two weeks, we plan to start with the implementation and, based on the feedback that you have provided, we would like to offer the following two solutions: > > 1. A management interface for sponsoring LIRs in the LIR Portal > > Sponsoring LIRs will be able to issue access credentials for the RPKI Management interface to either themselves if they manage ROAs on behalf of the PI End User, or directly to the PI End User if they have requested to set up and maintain ROAs. > > 2. A form on the RIPE NCC website, allowing PI End Users to request access directly from the RIPE NCC > > PI End Users will be able to log in with their RIPE NCC Access account, enter the resources they would like a certificate for and authenticate against the INETNUM database object to prove they have authoritative control over the address space. > Being a v4/v6/asn PI resource holder and not having access to the LIR Portal, I would prefer the second option. Thanks, -- Nat 07531 750292 http://natmorris.co.uk