On 04/02/2013 09:02, Hank Nussbacher wrote:

Which we will. We are trying to create a policy/framework to regulate NCC services in regards to LRH - which does not exist today.

The question everyone needs to answer is "is what has so far been sent better than no policy?" Do you support the general direction we are going in, ignoring the nits which can easily be fixed?

The general direction is great and I think this update to the proposal is a huge improvement on v1.0, but do not support the policy proposal as it stands because it still has critical problems. The most important of these problems is a discussion / decision about what to do with registration services for legacy resource holders / legacy resources who do not engage with the RIPE NCC. There are other serious problems with the proposal too, and a couple of nits which are easily fixable. Nick

Randy Bush wrote: [...]

...

It also provides multiple options for LRHs to completely ignore the RIPE NCC forever. I don't believe that this constitutes good stewardship of resource registration on the part of the RIPE NCC.

unfortunately, that is the status quo. and we kind of have a historical obligation to allow them to ignore the ncc. but perhaps a carrot, as opposed to a stick, can significantly improve this.

Indeed. Coming back after stating my general support yesterday, to one of the individual issues that may benefit from changes: I don't remember who already pointed fingers at the ROA service (thanks!), but we - eventually - may have a pretty convincing carrot by offering the "Certification of these data;" (which I read as being ROA and future friends) only to LHRs that have established a formal relationship and are paying for the service according to 2.1 ... 2.4. Certification is a service that has been developed recently by the RIRs, so IMO there is no legacy "right" here. This would apply for the cases described in 2.5 and certainly 2.6. [...]

---

i think sander said it well:

+1 Wilfried

...

This proposal tries to bring the legacy resource holders and the RIPE NCC together under mutually acceptable conditions to create a situation of good stewardship as far as possible. It won't be perfect. Address space got given away without any conditions attached at the beginning of the internet, and now we have to deal with that.

suggestions on how to better achieve these goals would be greatly appreciated of course.

randy

Randy Bush wrote:

...

Coming back after stating my general support yesterday, to one of the individual issues that may benefit from changes:

I don't remember who already pointed fingers at the ROA service (thanks!), but we - eventually - may have a pretty convincing carrot by offering the "Certification of these data;" (which I read as being ROA and future friends) only to LHRs that have established a formal relationship and are paying for the service according to 2.1 ... 2.4.

Certification is a service that has been developed recently by the RIRs, so IMO there is no legacy "right" here. This would apply for the cases described in 2.5 and certainly 2.6.

< as one of the proposers >

this carrot is not accidental. your first paragraph would seem to indicate that you would prefer to dilute this encouragement to form a formal relationship? am i misreading?

Yes, I think so :-( Trying again: in 1.1., there's a taxative list of services that includes Cerification, while 2.6 states: "In such a case, the RIPE NCC will *continue to provide those registry services which are already being provided* in respect of the Legacy Internet Resource or Resources involved, and may update the related entries in the RIPE Database from time to time to correspond to current actual situation." I read that as including Certification per the list in 1.1, or am *I* misrading here?

randy

Wilfried

On 05/02/2013 14:30, Randy Bush wrote:

...

I read that as including Certification per the list in 1.1, or am *I* misrading here?

that was not the intent

fwiw, i found this quite ambiguous too. It took several careful scans over the doc to figure out the intention. Some wordsmithing here would be quite beneficial. Nick

Randy Bush wrote:

...

...

that was not the intent

fwiw, i found this quite ambiguous too. It took several careful scans over the doc to figure out the intention. Some wordsmithing here would be quite beneficial.

sure. if you confused you and wilfried, then it's a problem for sure.

in the infamous words of vince perriello, send code :)

How about: " *Registry Services:* Services provided by the RIPE NCC in its capacity as a Regional Internet Registry, including the following traditional registry services, like ° 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; ° Delegation of reverse DNS to the registered DNS servers. and such additional or new services as may be identified from time to time as registry services, e.g. ° Certification of these data " Then, in Section 2.0 add to the first paragraph: " In these cases the RIPE NCC provides the full set of services to the LRH as technically or organisationally applicable. " Then in Secction 2.0 add to the second paragraph: " ....below in section 2.5, and the set of services is limited to traditional services. On a case by case bIechnically feasable and in the interest of both parties as well as the [RIPE|Internet] community. " Then in Section 2.0 add to the third paragraph: " The RIPE NCC will continue to provide the traditional services only, and only as long as this policy is in effect. " I know that the last part is redundant, as every policy can be changed in the future, but it may send the message that any LRH would be better off to Do The Right Thing[TM] *now*? Feel free to omit :-)

in the absence of contribution, i am sure someone far more diligent than i is tracking and hacking. is sure hope so.

randy

Wilfried.

On 5 Feb 2013, at 14:30, Randy Bush wrote:

that was not the intent

the sentence of 2.6 you quote would seem to refer to services NOW being provided to lrhs, which do not include certification.

+1 This is intended to ensure operational continuity per service/resource pair, not to create back-door access either to new services or to current services not already provided for a specific resource. An informal summary of the subsections in section 2 might read 2.1 .. 2.3: business as usual; 2.4: new business process for when "usual" doesn't fit a specific case; 2.5: exceptional accommodation for hard cases; 2.6: do no harm.

but any tweaks to wording to make things clearer greatly appreciated, i am sure.

Absolutely, and especially from anyone who sees a divergence between what is in the proposal and what I've offered as a summary above. /Niall

Here are some ideas for what could happen if a LRH wasn't engaging (in no particular order):

Removal of registration as a short term prospect: no-one is seriously in favour of this. It's unnecessarily destructive and will not entice anyone to engage with the RIPE NCC.

and is antithetical to the principal reason for the ncc's existence

Removal of some registration data as a short term prospect: e.g. drop DNS server entries. Again, I think this is unnecessarily aggressive.

and harms the rest of us, not the unresponsive entity.

Time limited amnesty: free registration for X period of time if you engage within Y period. Or some other carrot.

Free-for-all-time-for-everyone: as irresponsible as short-term deregistration.

this is the status quo and kinda what we are socially and technically committed to. we don't like it. the previously listed sticks are not really what we should be doing. so the proposal seeks carrots. i am quite open to alternative suggestions of tasty parsnips or rutabagas.

Inconvenience: locking of registration data for LRHs who decline to engage. I.e. the data still remains, but you cannot update the details, particularly the nameservers.

again, contrary to our primary mission, accurate data.

Removal of registration as a long term prospect: this will be necessary.

very hard procedurally and legally.

There is undoubtedly a pile of ERX address space which is either squatted or abandoned.

rigourously prove it such that it will stand up when we get our asses sued off. benefit::risk very very low.

As a long term objective, I think that there is some duty of stewardship that makes de-registration of data a requirement. Maybe we don't need to deal with it in 2012-07, but it is inevitable on a 20-50 year basis.

i think the costs of vigilatism are far more than the possible benefits. and 20-50 years from now, we will all be running in 10/8 anyway, or is it 100.64/10? randy

Hank Nussbacher wrote:

At 01:31 06/02/2013 +0000, Nick Hilliard wrote:

...

Removal of registration as a long term prospect: this will be necessary. There is undoubtedly a pile of ERX address space which is either squatted or abandoned. As a long term objective, I think that there is some duty of stewardship that makes de-registration of data a requirement. Maybe we don't need to deal with it in 2012-07, but it is inevitable on a 20-50 year basis.

I agree. If the inetnum or autnum is unused

In principle I agree, but I fail to see why this is a special case for LRHs? IMO this is outside the discussion of a policy for offering and administering registration *services* provided by the RIPE NCC.

and not routed

How would you, the NCC or actually anyone, "prove", that an address block is "not routed" (or in use)? We had that a couple of times already, it is a non-starter to begin with.

for the past 5 years, and all attempts at contact via email

There has been a good reason, why the email attribute has been optional :-) IMHO, nowhere in Internet-Policy and -Operations Land a requiement does exist or has ever existed to operate globally accessible port 25 services (or more modern versions thereof) in order to obtain address blocks or AS numbers for use in an IP-based (inter)network <please note the lowercase *i*>. OT - but maybe worth noting: the same expectation that such an obligation exists seems to be held by some parties in the abuse-management discussions...

to the data listed in whois, then by all means, initiate some sort of squatting/abandoned project.

As a (future) project, yes, with proper authorisation from the membership which has to foot the bill, and after reasonable assessment of cost vs. merits ;-)

But this has nothing to do with LRH, but should be a RIR policy.

Yes to part 1 and maybe to part 2.

-Hank

Wilfried

On 06/02/2013 16:36, Wilfried Woeber wrote:

Nick Hilliard wrote:

...

Removal of some registration data as a short term prospect: e.g. drop DNS server entries. Again, I think this is unnecessarily aggressive.

Not only "unnecessarily aggressive" but potentially destructive to the RIR system.

Then we agree that this shouldn't be done. Good! Nick

let's take the upside. i would suggest that there is a non-trivial number of lrhs who would be happy to form a more formal bond with the ncc to ensure their data are correct, and quite willing to pay a modest fee for the services currently provided for free. they just don't want to come under address policies and rights reduction of ncc membership. hence section 2.4. i would further suggest that 2.4 is a way to do reasonable certification of PI holders. randy

On Sun, 3 Feb 2013, Nick Hilliard wrote:

On 24/01/2013 13:33, Emilio Madaio wrote:

...

The text of the policy proposal 2012-07, "RIPE NCC Services to Legacy Internet Resource Holders", has been revised based on the community feedback received on the mailing list. We have published the new version (version 2.0) today. As a result a new Discussion Phase is set for the proposal.

ok, I'll bite.

in general, this is a vast improvement on v1.0 and I think it could feasibly form the basis of a working policy, but there are still some shortcomings and omissions which need to be dealt with.

In general yes. Well done so far.

LRH == legacy resource holder

minor nits:

- 1.0 introduction: some legacy resources were assigned by the InterNIC after the creation of the RIPE NCC, so it is incorrect to define LRHs as those who "were granted internet resources before the creation of the RIPE NCC". A similar comment applies to the definition given in 1.1.

Might seem minor but the definition certainly has to be correct.

- section 3.0: contractual requirements: I don't understand why there is a suggested contractual requirement to acknowledge that the terms and conditions of the original assignment are outside the scope of the new contractual arrangement, unless (straw man) someone can provide a copy of those T&Cs. I.e. this is probably unenforceable. I dunno. Looks odd to me.

- 4.0: "in cast the situation corresponds to section 2.5 above" - perhaps the authors may have omitted section 2.6?

larger grievances:

- I don't believe that there is a requirement for section 2.4. Disregarding that the RIPE NCC has ended the possibility of directly assigned resources for general PI holders (which I think has direct relevance to this), I don't accept that a legacy resource holder couldn't find one out of the current 8800 RIPE NCC members that wouldn't be appropriate for a sponsorship contract.

It does sound odd that when we are going away from the direct relation between the RIPE NCC and end users we are suggesting new relationships of the same kind. Find an LIR or become one. That should be enough.

- section 2.5: you can't be serious? "due to specific enduring or temporary circumstances"?? This is a carte-blanche for any LRH to ignore this policy until the heat death of the universe.

I feel a bit lost here. What circumstances are we talking about?

- there is probably a requirement for the LRHs to provide some form of formal identification about who they are and why they have a claim on the resources they claim to hold. For sure, the RIPE NCC cannot certify resources without a reasonable level of due diligence.

This is usually the biggest obstacle in my experience. We regularly help LRH:s with these matters and I think there should be clearer definitions of the paper work needed for identification. We are often talking about events 15-20 years back and since many LRH:s are large corporate groups they have often changed names and structure a few times since and now they have no idea what documentation to provide to prove they are acually the same entity.

- the proposed policy does not touch on the subject of transfer of resources to third parties. I think this should be dealt with, and that the RIPE NCC should be required to accept any transfer of resources to third parties.

- I'd like to see a requirement for publication of sponsorship details.

- the proposed policy does not touch on the subject of deregistration. I believe that it is important to deal with this, as otherwise the RIPE community has no mechanism for garbage collection of resources. The alternative is for the RIPE community to believe that the current set of LHRs will continue to exist until the fall of civilisation and that in this period, they will continue to be the canonical holders of the relevant resources. Not credible.

As a subset of this issue, the following sub-issues arise:

- there are no terms to deal with what the RIPE NCC should do with the resources in the situation where they are deregistered via whatever mechanism. I would suggest the IANA free pool.

- there are no terms to deal with the eventuality that a LRH might want to voluntarily deregister the resources.

- there are no terms to deal with the eventuality that all LRHs will eventually cease to exist, whether through bankruptcy, being forgotten, death, winding up, petition, etc.

- the root contention with this policy still remains: what happens to those organisations who decline to pay a registration payment and who decline to sign any contract? This policy proposal fails to establish a quid pro quo in this situation. The RIPE NCC does not operate on a zero cost basis, and it is only fair that those who depend on its registration services be required to pay for this. I can understand that many LRHs will have an idealogical objection to this but as King Lear said, "nothing will come of nothing".

suggestions:

- the RIPE NCC understands PA & PI address blocks. Would it be sensible from a service atomicity/equivalence point of view to suggest that LRHs who are RIPE NCC members receive exactly the same services as PA address holders (after due diligence on identity performed), and that LRH resources handled by sponsoring LIR be provided with the same services as PI address space?

- ASNs are the same for everyone, so it would probably be useful to declare that any LRH ASN will receive the same service level as any RIPE NCC-assigned ASN (obviously given suitable contractual link between resource holder and the RIPE NCC).

Nick

On the whole, very well put Nick. Best Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm

On Mon, Feb 04, 2013 at 01:12:43PM +0100, Daniel Stolpe wrote:

...

in general, this is a vast improvement on v1.0 and I think it could feasibly form the basis of a working policy, but there are still some shortcomings and omissions which need to be dealt with.

In general yes. Well done so far.

Agree.

...

LRH == legacy resource holder

minor nits:

- 1.0 introduction: some legacy resources were assigned by the InterNIC after the creation of the RIPE NCC, so it is incorrect to define LRHs as those who "were granted internet resources before the creation of the RIPE NCC". A similar comment applies to the definition given in 1.1.

Might seem minor but the definition certainly has to be correct.

OK, 1.0 introduction wording can be improved a bit. But, the definition in 1.1: -- Legacy Internet Resource: Any Internet Resource granted before the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries became operational. -- seems to mimic a definition of "Early registration" in ripe-581: https://www.ripe.net/ripe/docs/ripe-581/ ... 1.2 Early registration: IPv4 address space assigned or allocated before the establishment of the Regional Internet Registries (RIRs)." This ripe-581 definition of an early registration probably implicitly assumes a time point of establishing a RIR in the respective region an IPv4 address space was allocated/assigned through. Back to the proposed 1.1 wording, IMO the current system of hierarchical distribution is unlikely to be considered operational before InterNIC ceased to exist and ARIN became operational.

...

larger grievances:

- I don't believe that there is a requirement for section 2.4. Disregarding that the RIPE NCC has ended the possibility of directly assigned resources for general PI holders (which I think has direct relevance to this), I don't accept that a legacy resource holder couldn't find one out of the current 8800 RIPE NCC members that wouldn't be appropriate for a sponsorship contract.

It does sound odd that when we are going away from the direct relation between the RIPE NCC and end users we are suggesting new relationships of the same kind.

Find an LIR or become one. That should be enough.

Are you also suggesting that RIPE NCC should stop providing a PI holder (a non-member) with a possibility to become a Direct Assignment User via signing a direct contract with NCC (ripe-518)?

...

- section 2.5: you can't be serious? "due to specific enduring or temporary circumstances"?? This is a carte-blanche for any LRH to ignore this policy until the heat death of the universe.

I feel a bit lost here. What circumstances are we talking about?

Just thinking out loudly. Perhaps, a disputed resource holder identification or existence? That's a case when a second paragraph in the section 2.5 is to become applicable.

...

- there is probably a requirement for the LRHs to provide some form of formal identification about who they are and why they have a claim on the resources they claim to hold. For sure, the RIPE NCC cannot certify resources without a reasonable level of due diligence.

This is usually the biggest obstacle in my experience. We regularly help LRH:s with these matters and I think there should be clearer definitions of the paper work needed for identification. We are often talking about events 15-20 years back and since many LRH:s are large corporate groups they have often changed names and structure a few times since and now they have no idea what documentation to provide to prove they are acually the same entity.

Maybe RIPE NCC can help here, since mergers, takeovers and cease to exist situations do happen with LIRs or PI holders as well. And RIPE NCC is likely to have some experience in this area. Though, there are differences complicating the matter a bit. No initial relationship between the RIPE NCC and a LRH and a rather long time span. Have some of the related issues been sorted out during the ERX project? I support the proposed policy 2012-07 as it is. Sure, the text can be improved and I'm likely to restate the support in such case. Martin

Nick, On 3 Feb 2013, at 22:57, Nick Hilliard wrote:

ok, I'll bite.

Thanks for engaging so thoroughly! Apart from nits which I expect will be dealt with in due course, and points which are outside what I believe we (the co-authors) see as the scope of this proposal, I understand the following 2 points as your main ones.

- I don't believe that there is a requirement for section 2.4. [...] I don't accept that a legacy resource holder couldn't find one out of the current 8800 RIPE NCC members that wouldn't be appropriate for a sponsorship contract.

I see that as a guess. I hope you're right. If you are, keeping the section appears to be harmless; otherwise, it seems to be needed to fill an unfortunate gap.

- section 2.5: you can't be serious? "due to specific enduring or temporary circumstances"?? This is a carte-blanche for any LRH to ignore this policy until the heat death of the universe.

I believe that appropriate checks and balances are available. I expect that any LRH apparently claiming _undue_ special accommodation under this section would be likely to draw an uncooperative reaction from the RIPE NCC. Personally (I mean, representing the position neither of my employer nor of any of the co-authors of the proposal), I would find this quite reasonable. At such a stage, an aggrieved LRH acting in good faith would have recourse to the process of section 5.0. ATB /Niall

On 4 Feb 2013, at 14:18, Nick Hilliard wrote:

If you're going to propose a policy which gives carte blanche to LRHs never to pay a penny for all eternity in return for reliable registration services

I don't believe I am. You seem to be making a different reading of the proposal from the one I'm making. I've tried to address your objections to the proposed sections 2.4 and 2.5. Have I misunderstood what you meant? Have I perhaps left your "carte blanche" interpretation un-addressed because I've assumed it was derived from section 2.5? Is there something else I'm missing? ATB /Niall

At 15:21 04/02/2013 +0000, Nick Hilliard wrote:

On 04/02/2013 14:53, Niall O'Reilly wrote:

...

You seem to be making a different reading of the proposal from the one I'm making.

my reading of the proposal is that if a LRH wants to engage with the RIPE NCC for registrations services either directly or via a LIR or within existing / new LIR capacity, they can do so.

However, section 2.5 carves out an exception for organisations who feel that they are unable to sign a contract for whatever reason,

2.5 states "However, notwithstanding the preceding paragraph, the RIPE NCC may refuse to provide any specific registry service for which particular technical requirements apply, which the Resource Holder is unable to meet." So my reading is that for 2.5 - RIPE NCC can refuse any registry service.

and 2.6 carves out an exception for a broad category of organisations ranging from those who no longer exist to those who have no interest in engaging with the RIPE NCC and decline to answer their phone or reply to emails.

and 2.6 states "In such a case, the RIPE NCC will continue to provide those registry services which are already being provided in respect of the Legacy Internet Resource or Resources involved, and may update the related entries in the RIPE Database from time to time to correspond to current actual situation." What do you propose to do for an organization that got IPs in 1990, routes those IPs (meaning they are in use) and doesn't respond to any RIPE NCC email, letter or phone call? To me the options are: a) RIPE NCC just deallocates and deletes the allocated blocks b) RIPE NCC does nothing and does exactly what it does today I do not think RIPE NCC has a legal basis to do (a). That leaves (b). If you can find a better alternative please state it since it would be a welcome option. -Hank

This exception appears to entitle these resource holders to continued service on a permanent basis.

As an aside to this, the proposed policy and several other people have asserted that there is category of organisations who would be unable to sign a contract for ip registration services either directly or via a sponsoring LIR. Could you elaborate on some concrete examples of this? I'm finding it difficult to understand how the set of organisations who registered IP addresses in the years before 1992 are different from the set of organisations which registered IP addresses via the RIPE NCC such that it's not possible for the former to engage in contractual relationships which seem to be completely standard for the latter.

Nick

On 05/02/2013 20:42, Sascha Luck wrote:

On Sun, Feb 03, 2013 at 10:57:41PM +0000, Nick Hilliard wrote:

...

- section 2.5: you can't be serious? "due to specific enduring or temporary circumstances"?? This is a carte-blanche for any LRH to ignore this policy until the heat death of the universe.

Why wouldn't they? RIPE is not a government that can tax things that used to be free or make policy and charge fees for resources they do not own. IMO any LRH who wants to ignore this (and other) policies until the death of the universe is entirely justified in doing so.

If they want to ignore this policy, then they should go ahead and ignore it - until the heat death of the universe. I have no problem with that. The point is that running a registry costs money:

http://www.ripe.net/lir-services/ncc/gm/september-2012/documents/draft-ripe-...

The figures aren't particularly important in this context, but there are costs and they are not insubstantial. Given that there are tangible ongoing costs associated with running the registry, it's not unreasonable to expect that all resource registrants contribute to the running of this service through one mechanism or other. To be clear, I fully support sections 2.1 to 2.3 in the proposal and have no problem with e.g. LIRs which are legacy holders discharging any obligation of this form via their regular membership fees. My concerns relate to the relatively small number of organisations who feel that because they have not been asked to pay registry service fees since the resources were registered over 20 years ago, that the RIPE NCC is therefore obliged to provide ongoing registration services to them in perpetuity. I don't believe that this is a reasonable position to take because this position is all take and no give.

...

- there is probably a requirement for the LRHs to provide some form of formal identification about who they are and why they have a claim on the resources they claim to hold. For sure, the RIPE NCC cannot certify resources without a reasonable level of due diligence.

I should be very careful in proposing this in policy. Judging on past record, this will be implemented as an onerous pile of bureaucratic misery. Hardly likely to entice a LRH to engage with the NCC.

If you have alternative proposals for resource certification which don't involve some form of due diligence, I'd be mightily interested to hear them :-)

Is that a requirement that the NCC *accepts* the transfer or a requirement that the NCC has approval on thoise transfers?

to be defined. I agree with someone else's comments (can't remember who - Wilfried maybe?) that this is probably best dealt with separately. Best get this proposal dealt with first and then deal with other issues scu

Overall, the policy is still best summarised as: "It's a trap!" Well, as

No need to be scary-conspiratorial here. I'm not sure if you've noticed, but the holders of the address space are working towards a situation with the organisation which they own, which will benefit everyone in the long run. Oh wait, I left my tin hat off for a moment and the government mind control machine took over, zomg!! :-) Nick

On 06/02/2013 00:17, Randy Bush wrote:

i lost a small intra-author discussion in which i asked it to be explicit that small fee for ncc services would be paid (but not for rental of integers). would that make you happier with 2.4?

sorta, but it's a little more subtle than that. The issue isn't payment but how the payment should be made. We're all agreed that any talk of renting integers is silly now that the standard charging mechanism put an end to that (which makes lots of things much simpler actually). A services fee is appropriate, imo, but I believe that this would be better handled via a sponsoring LIR for the same reasons that apply to 2007-01. When 2007-01 became policy, the RIPE NCC originally provided a mechanism for a direct relationship and I'll be brutally honest in saying that I was horrified when they jacked that price up to the same as the membership fee, while keeping the sponsored fee at €50 - this wasn't what I intended at all when writing the policy; nor was it explicitly precluded by the policy. In retrospect it actually worked rather well. The RIPE NCC is a registry, not a registrar, and it would not benefit anyone for them to turn into a billing operation with a small registry arm on the side - or to compete with their members for registrar services. It also seems that there aren't big roadblocks to PI end users getting LIR sponsorship contracts in place - there are plenty of LIRs knocking around and they're all on the same footing. This allowed the RIPE NCC to dispense with the direct relationship arrangement for 2013 onwards (even though I note that they didn't ask or receive RIPE community support for a policy proposal to back this change), which has reduced the number of contract templates they need to deal with by one. This will reduce their paperwork, costs and overhead and there is inherent virtue in simplifying the bureaucracy involved. So from this context, I just don't see the need for 2.4. It's not that I have a major objection to it - it's simply that we have a precedent to show that it's not just unnecessary, but that it will increase the cost of implementation of this policy. We could go down this road again, but we've been there and done that and found it to be, well, slightly pointless. I'm happy that we don't need to go down the road again, but it's not a huge issue one way or another. Nick

On 06/02/2013 01:00, Randy Bush wrote:

but we do not know the real identity of those hiding behind lirs. would you want to certify them?

Where the identity of the holder is clear, and there are contractual links in place, yadda yadda due diligence, then yes. I think maybe it would be good to deal with the certification issue in a separate policy, because it's difficult. Nick

On 06/02/2013 01:33, Randy Bush wrote:

...

I think maybe it would be good to deal with the certification issue in a separate policy, because it's difficult.

definitely! we need more corner-case policies :)

If there isn't a policy to deal with this, de-facto due diligence policies will need be created by the registration services department to handle certification requirements for ERX users. So which do you want: - the community (including ERX users) to work out a set of guidelines for how to handle certification when the original documents are lost, or - the RIPE NCC RS department to invent something which works for them after being told, "uuh, you guys just go off and handle that and don't bother us too much with the details" - followed by some handwaving? KISS means keeping it as simple as possible, but no simpler. Nick

Subject: Re: [ncc-services-wg] 2012-07 Discussion Period extended until 21 February 2013 (RIPE NCC Service to Legacy Internet Resource Holders) Date: Thu, Feb 07, 2013 at 03:27:14AM -0800 Quoting Randy Bush (randy@psg.com):

one has to wonder what criteria and methods the ncc uses.

A common example is "If you can produce an electricity invoice addressed to the company, it is a piece in the puzzle. But the street address must match." That last requirement is interesting when the organisation, as has been the case with my last two employers, /does not have a street address/, but instead has a postcode uniquely allocated to it: Royal Institute of Technology 100 44 Stockholm Sweden ..and Sveriges Radio 105 10 Stockholm Sweden Yes, mail is delivered perfectly fine to those addresses. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 ... or were you driving the PONTIAC that HONKED at me in MIAMI last Tuesday?

Dear Randy, On 2/7/13 12:27 PM, Randy Bush wrote:

...

...

...

I think maybe it would be good to deal with the certification issue in a separate policy, because it's difficult. definitely! we need more corner-case policies :) If there isn't a policy to deal with this, de-facto due diligence policies will need be created by the registration services department to handle certification requirements for ERX users. well, to me, it's not a policy per se, but a requirement and a process. and it applies both to bringing legacy and pi in from the cold. i am more concerned with the requirements, what makes us comfortable in establishing that a claimant indeed is the legitimate holder of some resource(s). you seem to be more focused on making sure the process of meeting those requirements is not onerous. i think both are quite legitimate concerns.

Andrea's statement on this is interesting:

We have however built some experience reviewing proof of holdership of legacy resources over time. 84 organisations have asked the RIPE NCC to add their legacy resources to an LIR. As mentioned in this email thread, some cases have been straightforward while other cases have required in-depth research and review of documentation.

one has to wonder what criteria and methods the ncc uses.

Our experience has shown us that each case is unique and can require very different approaches to establish beyond doubt who is the legitimate holder of the resources. We start by checking to see if we have relevant information internally. This can take the form of internal database information, InterNIC documentation or communication from that period (faxes, letters, etc.). We then look at the corporate paper trail. This involves tracking companies that in many cases have changed name, merged with other companies, been acquired or simply closed down. In some cases there is quite a lot of information available and in others very little. In many cases, the available information turns out to be disputed or incorrect. All of this means that this is usually a time-consuming and resource-intensive process. Best regards, Andrea Cima RIPE NCC

randy

At 00:00 06/02/2013 +0000, Nick Hilliard wrote:

My concerns relate to the relatively small number of organisations who feel that because they have not been asked to pay registry service fees since the resources were registered over 20 years ago, that the RIPE NCC is therefore obliged to provide ongoing registration services to them in perpetuity. I don't believe that this is a reasonable position to take because this position is all take and no give.

So we agree we are talking about corner cases. Can you specify what you mean by "registry services"? Here is how I see it. Suppose we have 100 corner cases and they each own a /19. They have an auto-num, route and inetnum objects which is controlled by a mntner object. They send in an email to auto-dbm@ripe.net to update some phone number or email in order to keep the whois data uptodate. In my opinion, this is the only registry service they need and these 100 corner cases should be allowed to continue to do so. If they need something that requires human intervention - "anything", which can include a lost MD5 password for their mntner, then, at that point the RIPE NCC can state "pay membership dues in order for us to continue". -Hank

At 15:34 06/02/2013 +0900, Randy Bush wrote:

...

Suppose we have 100 corner cases and they each own a /19. They have an auto-num, route and inetnum objects which is controlled by a mntner object. They send in an email to auto-dbm@ripe.net to update some phone number or email in order to keep the whois data uptodate. In my opinion, this is the only registry service they need and these 100 corner cases should be allowed to continue to do so. If they need something that requires human intervention - "anything", which can include a lost MD5 password for their mntner, then, at that point the RIPE NCC can state "pay membership dues in order for us to continue".

s/memebrship dues/fees for the services/

Fine. -Hank

randy

On Wed, Feb 06, 2013 at 12:00:18AM +0000, Nick Hilliard wrote:

If they want to ignore this policy, then they should go ahead and ignore it - until the heat death of the universe. I have no problem with that.

The point is that running a registry costs money:

The figures aren't particularly important in this context, but there are costs and they are not insubstantial.

I don't think that the cost of providing basic, mostly automated, services is in any way high enough to make compromising the registry data an option. IMO, after we've seen where it leads to, the mindset of "nothing must ever be free and everything must be bought and paid for" has proven to be disingenous. Let those few LRHs that DNW to engage with RIRs have those services pro bono the database.

If you have alternative proposals for resource certification which don't involve some form of due diligence, I'd be mightily interested to hear them :-)

Bin it with extreme prejudice (at least in the form where the RIRs control the certificates).

No need to be scary-conspiratorial here. I'm not sure if you've noticed, but the holders of the address space are working towards a situation with the organisation which they own, which will benefit everyone in the long run. Oh wait, I left my tin hat off for a moment and the government mind control machine took over, zomg!! :-)

I'm happy with almost anything that does not involve a LRH being forced to give up any rights to their resources hitherto enjoyed. (I don't hold any LR, nor am I likely to ever do; this is a matter of principle to me) cheers, Sascha

On 05/02/2013 23:33, Randy Bush wrote:

mornin' nick,

btw, the approach of hiding behind an lir is somewhat interesting.

for an r&e institution, such a janet or nordunet member, the reliability of the information about the end user may be strong enough to allow the ncc to be comfortable.

in the non-r&e space, it would seem to be just creating more of the same problem we have with PI space. 'hiding' behind an lir would be too much hiding and not enough lir.

actually if there were some non-discriminatory way of doing this, I wouldn't be averse to the idea - this is a helpful side-effect of the new level-field charging mechanism. Problem is, however much the R&E organisations tend to be decent, honest and upstanding members of the Internet community, I don't see how it would be feasible to implement this without being unfair to the non R&E resource holders. Level playing fields are important as a policy goal.

as you can see, most of the authors of 2012-7 are r&e folk, and much of the legacy resources holdings in the region are r&e.

Most of the legacy resources still in use are R&E, but a substantial chunk of the squatted / abandoned space was never R&E to start with. The issues that I have with the current proposal relate to how it will handle these problem address blocks. Nick

Hi Robert,

This proposal seems to me to provide a reasonable balance between legacy holders existing rights and the community's wish to improve the accuracy of registration data.

It provides for several options relating to the engagement between the legacy holders and RIPE, in recognition of the wide range of organisations who are legacy holders.

That was our aim when writing the text :-)

I therefore support this proposal

Thanks, Sander

Hi Nick,

...

It provides for several options relating to the engagement between the legacy holders and RIPE, in recognition of the wide range of organisations who are legacy holders.

It also provides multiple options for LRHs to completely ignore the RIPE NCC forever. I don't believe that this constitutes good stewardship of resource registration on the part of the RIPE NCC.

I think the point here is that the RIPE NCC wasn't involved in the original resource registration in the first place. I think it's (legally?) not possible to force legacy holders to work with the RIPE NCC because they got their address space before the RIPE NCC even existed and/or started to register resources with no strings attached, and I don't think you can expect the RIPE NCC to maintain good stewardship for resources that they don't have strings on... (probably not good English, but I hope you understand what I mean ;-) This proposal tries to bring the legacy resource holders and the RIPE NCC together under mutually acceptable conditions to create a situation of good stewardship as far as possible. It won't be perfect. Address space got given away without any conditions attached at the beginning of the internet, and now we have to deal with that. Thanks, Sander

On 4 Feb 2013, at 12:21, Nick Hilliard <nick@netability.ie> wrote:

but payment for services received is fundamental.

Nick, I agree with the general principle that everybody using NCC services should pay their fair share. However IMO it would be best to apply a bit of compromise and pragmatism in this case. The "core" service for legacy holders is maintaining the database objects for those resources. The supporting infrastructure for that -- database systems, DNS/whois servers, LIR portal, etc -- already exist. So the incremental cost to the NCC of making that platform available to legacy holders should be very low. It may well cost the NCC more to bill legacy holders for a few Euro each time they change a reverse DNS delegation or update a contact object. I'd be very uneasy about introducing measures (ie fees) which discourage legacy holders to keep their registration data up to date. After all what's *really* more important here, a complete (ish) registration database that can be relied upon or some accountancy paperwork? On-going care and maintenance of the registration database is the NCC's prime reason to exist. IMO, that means the NCC has inherited the overheads of proving that for the legacy holders in its service region and is stuck with that. It's simply the cost of doing business and the NCC just has to suck it up. Sorry. I'm sure the NCC staff and board will keep an eye on the actual costs of providing registration services "for free" to legacy holders if 2012-07 is passed. If those costs turn out to be a burden, we should trust The Management to bring this to the attention of the WGs and the NCC membership. So let's get on with adopting 2012-07. The policy can always be reviewed in light of actual experience. Personally, I disagree with the definition of Registry Services in 2012-07. IMO it should not include certification of registration data. [If legacy holders want that, they should become NCC members as far as I'm concerned.] After all, resource certification was not a service which existed when the legacy holders originally got their resources. So the services they get "for free" now should be the same as the services they got for free from the InterNIC. However I go along with the definition in 2012-07 as a compromise in order to help arrive at a consensus policy. I hope you can compromise too. BTW, there's a lot of irony on my part here. I don't represent an LIR or legacy holder. There's a fair bit hypocrisy too because I'm a strong advocate of the NCC not doing stuff "for free". And now I'm another non-member suggesting how NCC members' money gets spent. So shoot me... PS: apologies for using a meaningful Subject: header. :-)

On 04/02/2013 22:12, Måns Nilsson wrote:

The "completely estranged LRH holder organisation" is not that common, I believe. Wasting electrons on this corner case is not fruitful.

Problem is, I'm not sure it's a corner case; nor am I sure that the squatters are corner cases, nor the abandoned address blocks. Has the RIPE NCC done any preliminary analysis of the ERX space in terms of: - rough consistency of link between inetnum: owner and mntner - when was the last time the resources were updated - potential LIR association - whether prefix is visible in dfz I realise that this is very ill-specified. This might be useful in quantifying how much effort it would be worth expending in what you and Hank refer to as "corner cases", but which I would feel were more common. Nick

On 06/02/2013 20:33, Måns Nilsson wrote:

It's been mentioned (and with good backing I believe, I've seen it from the inside) that a lot of old assignments are to RE networks. Most of these are reasonably well maintained. My own limited knowledge of commercial entities having assignments points to similar data. Mostly. (both I and my wife work at corporations with ERX blocks -- my block has a current maintainer and a route object, her block has ERX info which still is correct, at least points to the right company)

I'm sure the early academic community assignments are generally accurate and well maintained, which is unsurprising given the stability of the institutions which hold them. And I don't doubt their good faith for a moment. Having said that, I also know that some blocks which I registered for my (commercial) employer at the time via InterNIC have somehow ended up in the possession of one of the local LIRs in IE. Other address blocks that I've browsed through look defunct; others look decidedly squatted. There seems to be quite a mixed bag.

My belief thus is, that most of these entries are good enough that they serve a purpose. Some of them are excellent. A better picture can probably be had by some more dedicated data-mining.

Some visibility into the data quality would be very useful at this stage, because from a policy point of view, it would helpful to know whether we are tilting at windmills or trying to fix a problem which is worth fixing. My suspicion veers towards the latter; the opinion of many other people appears to be the former.

I am quite upset with a heavy-handed policy being crafted to force every possible net into a rigid form. Yes, I've argued that the RIR database needs to be complete. And it is in fact so important that estranging (which heavy policies will lead to, I'm afraid) is detrimental.

I can understand why. As I said, I don't doubt your good faith - or the good faith of anyone else who's contributed to this discussion. But there is a real mess there and undoubtedly there will be people and organisations less well intentioned than you who will attempt to abuse the situation to benefit themselves at the cost of everyone else. What I'm trying to do here is tease out whether it's possible get a balance between the two.

Ultimately, the NCC and the other RIRen have no actual power over early registrations/allocations.

Nobody disputes this, but the RIPE NCC as de-facto registrar has a duty of good stewardship to these addresses, just as ERX holders have an expectation of good service. Coming to an agreement on where each side stands is something that will benefit everyone. Nick

Hi Nick, All, On 2/6/13 3:30 PM, Nick Hilliard wrote:

On 04/02/2013 22:12, Måns Nilsson wrote:

...

The "completely estranged LRH holder organisation" is not that common, I believe. Wasting electrons on this corner case is not fruitful. Problem is, I'm not sure it's a corner case; nor am I sure that the squatters are corner cases, nor the abandoned address blocks.

Has the RIPE NCC done any preliminary analysis of the ERX space in terms of:

- rough consistency of link between inetnum: owner and mntner - when was the last time the resources were updated

- According to the initial ERX transfer list, 339 inetnum objects have been deleted. This may however mean that more specific objects have been created by the maintainer. - 393 inetnum objects have RIPE-NCC-LOCKED-MNT in the mnt-by line. These objects were registered in the RIPE DB before the ERX transfer took place, and were maintained using RIPE-NCC-NONE-MNT. When this was deprecated the RIPE NCC locked all objects referencing it. As these objects are still locked, no one is currently managing this data. - 851 inetnum objects have the ERX auto-generated maintainer (in the form ERX-NET-138-81-MNT) as mnt-by. The holders 'may' have been given the password and are 'able' to manage this data, but may or may not have done so. Others were not given the password and are not managing the data. Without deeper analysis we can't separate these groups. - 764 inetnum objects have replaced the ERX aut-generated maintainer (in the form ERX-NET-138-81-MNT) with a different maintainer. This is a clear indication they have taken control of this data since the transfer. - 1835 inetnum objects have the following line removed (which was added during the ERX project) 'remarks: **** INFORMATION FROM ARIN/RIPE OBJECT ****' This is an indication they have taken control of this data since the transfer. - 141 inetnum comply with none of the above. The inetnum objects contain no RIPE-NCC-LOCKED-MNT maintainer and never contained an auto-generated maintainer, and still contain the ERX remarks lines. Without deeper analysis we cannot say anything about this group. I hope this provides you with enough information to quantify the effort. If more information is needed we can do a deeper analysis of the numbers above.

- potential LIR association

To identify potential LIRs we looked at the ASes which were seen originating prefixes from the ERX space in RIS in the last week. Out of the 4050 ERX blocks, we found 1498 cases where (partly) matching prefixes have an origin AS which can be associated an LIR. In total 775 unique ASNs were found: - 89 of the 775 AS numbers are registered with an RIR other than the RIPE NCC - 109 of the 775 AS numbers have been transferred to the RIPE region during the ERX project but are not associated to an LIR - 577 of the 775 AS numbers are associated (directly or via sponsoring) to 365 unique LIRs

- whether prefix is visible in dfz

Of the 4,050 entries we found, 1,673 IP ranges are currently not in RIS (not visible in the routing tables) - they have not been seen for at least one week. This includes more specific IP ranges than the ones registered. I hope this helps. Best regards, Andrea Cima RIPE NCC

I realise that this is very ill-specified.

This might be useful in quantifying how much effort it would be worth expending in what you and Hank refer to as "corner cases", but which I would feel were more common.

Nick

...

- 393 inetnum objects have RIPE-NCC-LOCKED-MNT in the mnt-by line. These objects were registered in the RIPE DB before the ERX transfer took place, and were maintained using RIPE-NCC-NONE-MNT. When this was deprecated the RIPE NCC locked all objects referencing it. As these objects are still locked, no one is currently managing this data.

possibly because they are correct and do not need change. we have no way of knowing.

...

- 851 inetnum objects have the ERX auto-generated maintainer (in the form ERX-NET-138-81-MNT) as mnt-by. The holders 'may' have been given the password and are 'able' to manage this data, but may or may not have done so. Others were not given the password and are not managing the data. Without deeper analysis we can't separate these groups.

again, the owners may be quite happy with the data as they are.

Interesting. So at the moment, it looks like between 30%-40% (i.e. from (393+851)/4050 to (339+393+851)/4050) of the ERX address space is arguably abandoned

from a measurement point of view 'arguably' may be the most important word in that sentence unfortunately we have never come up with a method to classify space rigorously. hard problem. and i am not optimistic. look at the recent noise about the uk gov /8 that looked unmaintained. randy

On Sat, 23 Feb 2013, Randy Bush wrote:

...

...

- 393 inetnum objects have RIPE-NCC-LOCKED-MNT in the mnt-by line. These objects were registered in the RIPE DB before the ERX transfer took place, and were maintained using RIPE-NCC-NONE-MNT. When this was deprecated the RIPE NCC locked all objects referencing it. As these objects are still locked, no one is currently managing this data.

possibly because they are correct and do not need change. we have no way of knowing.

Yes. And when the owners want an update they may be locked in the process och showing that they are in fact the right owners. We have a customer, a large corporate group that everybody in my country knows about and I would even say most people would agree that the original owner of a /16 is now part of this group and ask no further questions but what documentation is there now from a merger in 2000? Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm

Hi, On Mon, Feb 25, 2013 at 10:16:14AM +0000, Nick Hilliard wrote:

The flip side of this argument could be taken as: this holder's interest in maintaining their /16 (i.e. probably infrastructure which is very important to their business) is so small that in a period of 13 years, they couldn't be bothered spending a couple of hours updating the registry details for it.

If everything works, why would they need to even think about it? Like: still using the same AS to announce it, still using the same set of nameservers - so there was never a need to update anything due to "things not working on the technical side", so I can see why no updates have ever done... Our /16 PA allocation is from 1996, and all the updates on the inetnum: are hostmaster@ripe.net in 2002, 2004 and 2010 - and I'd bet all but one of these have been automated due to RIPE DB structural changes. The route: object is unchanged since 2002, since *there have not been any changes*. So I'm not sure why a PI /16 holder would have more need for updates, if nothing changed... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Hi, On Mon, Feb 25, 2013 at 10:28:30AM +0000, Nick Hilliard wrote:

On 25/02/2013 10:21, Gert Doering wrote:

...

If everything works, why would they need to even think about it?

e.g. to provide a credible means of rescue in the case of registry hijacking? A /16 isn't a ?9.99 kettle which you can easily replace down in the local hardware shop.

...

So I'm not sure why a PI /16 holder would have more need for updates, if nothing changed...

The whole point is that something has changed in the situation that Daniel referred to: the legal name of the resource holder.

Sure. But still, "if it all works, why would they even remember that the RIPE NCC exists"? The human brain works like that... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

On 25 Feb 2013, at 10:16, Nick Hilliard <nick@netability.ie> wrote:

Leaving things for so long in a situation like this is likely to cause difficulties, but registrants have a duty of care to their infrastructure.

True enough. Though it depends on how "duty of care" is defined. Engagement with an RIR may well not matter for an LRH. If their intranet works just fine thank you very much and isn't reachable from the Internet anyway, what would be the appropriate duty of care from such an LRH's perspective? Problems would most likely arise whenever they eventually do have to engage with their RIR, just like you said Nick. And if they don't need to engage... I would not be at all surprised if some LRHs are unaware that they have those resources* or that this could entail maintenance of entries in RIR database(s). [*They may well be using those IP addresses but have difficulty providing the paperwork which shows how they got them or who is/was responsible for that.] The internal paper trail for the space could well be flimsy or non-existent. It may rely on (lost) institutional memories. But provided everything "just works", why would such an LRH bother or need to care?

Hi, On Mon, Feb 25, 2013 at 11:43:49AM +0000, Nick Hilliard wrote:

On 25/02/2013 11:35, Jim Reid wrote:

...

But provided everything "just works", why would such an LRH bother or need to care?

My car "just works" until it burns enough oil that the engine seizes up.

So where's the red light "hey, you need to update your resources at the RIPE NCC"? The car has that (... and reasonably recent cars don't use up that much oil anyway, so regular maintenance cycles *do* take care of that). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279

Daniel Stolpe wrote:

On Mon, 25 Feb 2013, Nick Hilliard wrote:

...

On 25/02/2013 09:56, Daniel Stolpe wrote:

...

Yes. And when the owners want an update they may be locked in the process och showing that they are in fact the right owners. We have a customer, a large corporate group that everybody in my country knows about and I would even say most people would agree that the original owner of a /16 is now part of this group and ask no further questions but what documentation is there now from a merger in 2000?

Probably lots if they were large enough to get a /16.

Of course their is documentation somewhere.

Not necessarily. In the "old days" quite a bit of networking and address distribution was done over the phone, on fax or by using non-IP-based eMail. One such example /16: status: ASSIGNED PI changed: porten@mvs.gmd.de 19900816 That's the date when it was possible(!) to register in the RIPE DB. The address block itself was obtained in the context of an IBM-related research project. Does anyone expect the current holder and user to still have a "paper trail"? Wilfried

But for a technician to get hold of exactly the right paper provning that the entity formerly known as A is now a part of the entity B might not be an easy task.

Regards,

Daniel Stolpe

_________________________________________________________________________________

Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm

On 25 Feb 2013, at 10:48, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:

Exactly because of the complexity, the NCC should require payment for registration services to handle the request.

I'm not so sure. In principle, yes of course everyone should pay. OTOH, the costs of generating these bills might not be worth the effort in some cases. It could also put an extra (excessive?) load on the NCC's finance and legal people -- changes to finance systems and bookkeeping, new invoice/payment tracking procedures, T&C's for these transactions, etc, etc. Setting up all of that just so a phone number in an LRH contact object could be changed (say) that might well be overkill. My preference would be for the NCC to provide the same services to LRHs that they got from the old Internic under the same terms and conditions: ie "for free". IMO, that's just part of the cost of doing business for an RIR. For any other services -- for instance getting an RPKI cert or adding a DNSSEC key for reverse DNS -- an LRH should pay. Ideally, they would do that by becoming an LIR or going through a sponsoring LIR. That way there would be no need to change the NCC's existing finance systems and processes. If this is not acceptable, then we need to be careful that whatever cost recovery mechanisms get proposed do not impose unwelcome overheads on the NCC. I wish we could get some hard data about this now instead of waiting until the proposal gets to the impact assessment stage. For instance, how many of these LRH transactions are expected each year, what sort of financial systems and processes will be needed to handle them, what will these cost. I fear we could be proposing something that grows into a cumbersome bureaucracy that needs a small army of beancounters to manage it. It would be nice if we could reach consensus on something that is workable before going to impact assessment and then finding the proposal is impractical because of the load/costs it imposes on the NCC.

On 27/02/2013 14:04, Wilfried Woeber wrote:

do exist. So, unless someone in Amsterdam wants to see "paper", the whole thing is easy and cheap: the sponsoring LIR confirms the existence of the org and the connectivity to e.g. the NREN. Full stop. Pretty simple + cheap :-)

so will this be enough to satisfy legal due diligence? I'm asking, btw - I don't know what the answer is. Nick

Nick Hilliard wrote:

On 27/02/2013 14:12, Nick Hilliard wrote:

...

so will this be enough to satisfy legal due diligence

... for e.g. certification.

If we take a step back and try to model the tree/mesh of responsibility on the operational reality, and install a structure with CA and RA(s), then, imho, YES.

Nick

But the question regarding "legal due diligence" may be asked the other way 'round, too: we've got a holder and user of a resource, and someone (an RIR) questions the rightfulness (is this an engl. word?), then wouldn't it be "fair" for that party to come up with the "documentation", from a legal pov? I know that this is sort of "funny", from an abuse/security perspective. But, what I want to achieve and argue for, is to decouple the registration service from the operational (ab)use aspects. The Registry does have a clear mandate for the former, but not really for the latter. Wilfried.

On Wed, 27 Feb 2013, Wilfried Woeber wrote:

Nick Hilliard wrote:

...

On 27/02/2013 14:12, Nick Hilliard wrote:

...

so will this be enough to satisfy legal due diligence

... for e.g. certification.

If we take a step back and try to model the tree/mesh of responsibility on the operational reality, and install a structure with CA and RA(s), then, imho, YES.

...

Nick

But the question regarding "legal due diligence" may be asked the other way 'round, too: we've got a holder and user of a resource, and someone (an RIR) questions the rightfulness (is this an engl. word?), then wouldn't it be "fair" for that party to come up with the "documentation", from a legal pov?

I know that this is sort of "funny", from an abuse/security perspective. But, what I want to achieve and argue for, is to decouple the registration service from the operational (ab)use aspects.

The Registry does have a clear mandate for the former, but not really for the latter.

Wilfried.

Well put Wilfried. I agree. Regards, Daniel Stolpe _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe@resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 13 054 556741-1193 103 02 Stockholm

On 25/02/2013 14:35, Andrea Cima wrote:

We have the following information publicly available. However, this does not include data on transfers that occurred before the ERX project took place, or IP ranges transferred by the RIPE NCC to other RIRs.

http://www.ripe.net/lir-services/resource-management/erx/completed-transfers

This is missing all of the assignments for 192/8, 198/8 and 196/8. Nick

On 25/02/2013 15:06, Andrea Cima wrote:

You are correct. These are listed here: ftp://ftp.ripe.net/erx/

I will get the webpages updated with the 192/8, 198/8 and 196/8 information.

actually, would the converse be possible? I.e. that ftp://ftp.ripe.net/erx/ could contain the transferred blocks for the other /8s? Nick

Hi Nick, On 2/25/13 4:08 PM, Nick Hilliard wrote:

On 25/02/2013 15:06, Andrea Cima wrote:

...

You are correct. These are listed here: ftp://ftp.ripe.net/erx/

I will get the webpages updated with the 192/8, 198/8 and 196/8 information. actually, would the converse be possible? I.e. that ftp://ftp.ripe.net/erx/ could contain the transferred blocks for the other /8s?

As requested we have moved the transferred blocks to ftp://ftp.ripe.net/erx/ Best regards, Andrea Cima RIPE NCC

Nick

On 4 Feb 2013, at 11:59, Sander Steffann <sander@steffann.nl> wrote:

This proposal tries to bring the legacy resource holders and the RIPE NCC together under mutually acceptable conditions to create a situation of good stewardship as far as possible. It won't be perfect. Address space got given away without any conditions attached at the beginning of the internet, and now we have to deal with that.

+1 IMO the revised proposal is the least-worst pragmatic way of dealing with the issue. It's doubtful anything better could be developed or that a quest for perfection would be successful some time before IPv6 runs out. Let's fact it: some legacy holders will want to bring their resources inside the NCC tent and others won't or can't. No amount of debate here will change that. The latest version of 2012-07 deserves support. We should also remember if 20120-7 gets passed and then turns out to have been a mistake, it can be fixed later. Our policy making process should be responsive to the needs of the community and the prevailing circumstances.