March 2005 - address-policy-wg

IPv6 Policy Clarification - Initial allocation criteria "c)"
by Laura Cobley 19 Jul '05

19 Jul '05

Dear Colleagues, As explained in the email sent on Mon, 14 Jun 2004: http://www.ripe.net/ripe/mail-archives/address-policy-wg/2004/msg00240.html This is the second mail request for clarification of the IPv6 Address Allocation and Assignment Policy. Below is an excerpt from the IPv6 Address Allocation and Assignment Policy: 5.1.1. Initial allocation criteria "c)" "To qualify for an initial allocation of IPv6 address space, an organisation must [...] plan to provide IPv6 connectivity to organisations to which it will assign /48s by advertising that connectivity through its single aggregated address allocation" LIRs who operate closed/private networks appear not to qualify because the address space in these networks will not be advertised. Was this the community's intention? Best Regards, Laura Cobley Registration Services RIPE NCC

9 12

Policy proposal: #alpha: TLD Anycast Allocation Policy
by Hans Petter Holen 11 Jul '05

11 Jul '05

Dear all, Please find enclosed a policy proposal. As per my previous message I will "beta-test" the new PDP on this proposal. The current proposal has been discussed previously and has now been re-formulated after that discussion. My proposal is to enter this proposal into the Discussion Phase with a time line of 2 weeks ending on April 4th. Best Regards, Hans Petter 1.Number (assigned by the RIPE NCC) alpha 2.Policy Proposal Name: TLD Anycast Allocation Policy 3.Author a.name: Andreas Baess b.e-mail: baess(a)denic.de c.telephone: +49 69 27235 0 d.organisation: DENIC e.G. 4.Proposal Version: 1 5.Submission Date: 6.Suggested WG for discussion and publication: Address Policy Working Group 7.Proposal type: new 8.Policy term: renewable 9.Summary of proposal To enable ccTLD and gTLD nameserver operators to provide their DNS service using shared unicast technology, RIPE NCC is able to assign one IPv4 and IPv6 prefix per operator that is not likely to be filtered by common practise for anycast-operation of their DNS services. 10. Policy text a.Current: N/A b.New: "If the nameserverset of a TLD without anycasting technology applied would not pass the IANA Administrative Procedure for Nameserver Delegation and Glue Data (http://www.iana.org/procedures/delegation-data.html) may receive dedicated network prefixes for the sole purpose of anycasting name servers, as described in RFC 3258. These shall be: one /24 IPv4 prefix and/or one /32 IPv6 prefix per operator. The prefixes shall be tagged as 'ASSIGNED ANYCAST' in the RIPE database and MUST be returned to the RIPE NCC if not in use for anycast DNS any longer." 11. Rationale: PROS A. Acceptance of DNS for special treatment Studies like http://www.ripe.net/ripe/meetings/ripe-45/presentations/ripe45-eof-rickard.… shows clearly that ccTLD and gTLD nameservers are a critical network infrastructure that justify special policies to guarantee operability of Internet applications. B. Policy Harmonization Three out of four RIRs (APNIC, ARIN and LACNIC) have policies allowing assignments to network critical infrastructure. All three policies classify TLDs as critical infrastructure. Extracts from these policies can be found in Appendices I through III. C. Scalability of DNS To serve the projected increase of DNS queries and to ensure sufficient network topological coverage and diversity TLD managers need to deploy an increasing number of nameservers. D. Resilience Internet has become part of the daily life and their availabilty is as important as the availability of all public services. Anycasting is currently the state-of-the-art solution to lower the impact of DDoS attacks. E. IPv6 Support As the world starts exploiting IPv6, the DNS infrastructure should support IPv6 natively. However it is not yet possible to reduce the number of nameservers in the IPv4 cloud. CONS F. Waste of Address Space Accepting a number of IPv4/24 and IPv6/32 allocations for critical network infrastructures does not align with the traditional address conservation efforts. With anycasting it is very likely that only a few addresses from the entire assignment would be used. 2. Root DNS are special, others are not RIPE document 233 dated from 24th May 2002 says: "Although it is undesirable to give special status to any IP (IPv4 or IPv6) address block, it was agreed by the community that the particular need defined in this document is the only justifiable exception to that general principle." 3. Assigning an own network prefix is just a workaround to ensure global reachability which could also be achieved by adjusting currently deployed route filter practices. Appendix I APNIC Policy (Following section is taken from http://www.apnic.net/docs/policy/add-manage-policy.html - 11.3) 11.3 Critical infrastructure The following critical infrastructure networks, if operating in the Asia Pacific region, are eligible to receive a portable assignment: * root domain name system (DNS) server; * global top level domain (gTLD) nameservers; * country code TLD (ccTLDs) nameservers; * IANA; * Regional Internet Registry (RIRs); and * National Internet Registry (NIRs). Assignments to critical infrastructure are available only to the actual operators of the network infrastructure performing such functions. Registrar organisations which do not actually host the network housing the registry infrastructure, will not be eligible for an assignment under this policy. The minimum assignment made under these terms is /24. Appendix II ARIN Policy (Following section taken from http://ww2.arin.net/policy/index.html#four4) 4.4. Micro-allocation - ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. These allocations will be no longer than a /24 using IPv4 or a /48 using IPv6. Multiple allocations may be granted in certain situations. Appendix III LACNIC (Following section is taken from http://lacnic.net/policy-en.pdf) 3.3.3 Micro Allocations Micro allocation is the name given to those allocations that imply blocks smaller than /20 but always larger than or equal to /24. LACNIC can grant this type of allocation in case of projects and infrastructure for networks that are key or critical for the region, such as IXPs (Internet Exchange Points), NAPs (Network Access Points), RIRs, ccTLDs, among others. In the case of IXPs or NAPs, in order to be able to apply for this type of allocation, organizations shall meet the following requirements: 1. Duly document the following aspects: 1. 1Prove by means of their bylaws their capacity of IXP or NAP. The organization shall have at least three members and an open policy in relation to the association of new members. 1. 2Submit a company structure organizational diagram. 1. 3Document the numbering plan to be implemented. 2. Provide a usage plan for the following three and six months. The rest of the applications shall be studied based on the analysis of the documentation justifying the critical and/or key aspects of the project. Organizations receiving micro allocations are not authorized to suballocate these addresses.

8 12

HD ratio policy proposal
by BIDRON Alain ROSI/DAS 01 Jul '05

01 Jul '05

Dear Colleagues Referring to the minutes of the last RIPE Policy Working Group meeting and to the action list as updated during that meeting, I have to make a formal proposal on use of HD ratio for IPV4. Here is this policy proposal. In order to be consistent with the PDP Draft proposal coming from Rob Blokzijl I have used the template provided in the new PDP proposal. Best regards. Alain _________________________________________________________ 1. Policy Proposal Name: IPv4-HD-Ratio 2. Author a. name: Alain Bidron b. e-mail: alain.bidron(a)francetelecom.com c. telephone: +33 1 44 44 27 75 d. organisation: France Telecom 3. Proposal Version: V0 4. Submission Date: 02/02/2005 5. Suggested WG for discussion and publication: Address Policy WG 6. Proposal type: modify 7. Policy term: permanent 8. Summary of proposal: Internet address space is managed hierarchically: - IANA allocates space to Regional Internet Registries (RIRs). - RIRs allocate space to Local Internet Registries (LIRs). - LIRs assign space to End Users. At each level, some address space may be reserved for future expansion and/or efficient aggregation. As more hierarchical levels are introduced, the overall efficiency of the address space usage decreases. The HD ratio (Host-Density ratio) is a way to measure address space usage [RFC 3194]. The HD ratio value can relate to a percentage of usage, which decreases as the amount of address space grows. This allows for the decreasing efficiency that occurs with more hierarchical levels. The HD ratio is currently used to measure IPv6 address space usage [ipv6-address-policy]. The IPv6 Address Allocation and Assignment Policy considers a block of IPv6 address space to be ‘used’ when its HD ratio reaches 0.80. This is a manageable figure ("values of 80% or less correspond to comfortable trade-offs between pain and efficiency" [RFC 3194]). This document proposes using the HD ratio to measure IPv4 usage. The proposed value of the HD ratio for IPv4 is 0.96. 9. Policy text: a. Current: "An LIR may receive an additional allocation when about eighty percent (80%) of all the address space currently allocated to it is used in valid assignments or sub-allocations." b. New: "An LIR may receive an additional allocation when its total allocated address space usage meets the HD-Ratio value of 0.96." 10. Rationale: a. Background The current document, “IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region” [ipv4-address-policy], considers a block of IPv4 addresses to be ‘used’ when 80% of the addresses within the block have been sub-allocated or assigned. This is applied to all address blocks, regardless of size. Current policies assume a hierarchical system of address space delegation. However, they do not make any allowance for hierarchical management within allocated address space. For LIRs in particular, a hierarchical approach is often required for assignment of address space to service elements such as customer networks, individual Points of Presence (PoPs), regionalised topologies, and even distinct ISP products. Small network infrastructures may require simple hierarchies, but large infrastructures can require several levels of address space subdivision. These levels of hierarchy are not recognised by the current policy framework and are highly restricted by the "80% rule". As a result, managing large blocks is often difficult, requiring large internal routing tables and/or frequent renumbering of internal address blocks. One of the goals of the RIR system is to avoid unnecessary depletion of IPv4 address space. However, address management policies must also be practical in terms of how much management overhead they cause. When large amounts of address space are involved, the "80% rule" can result in more work for an LIR. Basing usage on the HD ratio should lead to equal levels of management overhead across the board, rather than penalising the holders of large address blocks. b.Impact To see a rough estimation of the immediate impact of this proposal, an HD Ratio value of 0.96 was applied to the average amount of address space held by an LIR in the RIPE NCC Service Region. This showed that on average, LIRs would qualify for an additional allocation block when they have assigned or sub-allocated about 59% of their allocated address space. c.Arguments supporting the proposal. This proposal fairly takes into account addressing hierarchies used in large and extra-large registries and introduces a useful level of flexibility for those registries The local Internet registries using the 80% criteria may continue to do so and will not be impacted by the new policy. The RIPE NCC will provide support to minimise complicated calculations or administrative burden to LIRs. d. Arguments opposing the proposal. This proposal will have some limited impact on IPV4 address consumption. Appendix A. The HD ratio The HD ratio is calculated as follows [RFC 3194]: HD = log(U)/log(S) Where: S is the size of the address block concerned, and U is the number of addresses used. Note: The current IPv4 policy considers addresses to be ‘used’ once they are assigned or sub-allocated by the LIR. Appendix B. Selection of HD ratio value We should decide an appropriate HD ratio value on a rational basis. To do this, we make certain assumptions about the number of "hidden" hierarchical levels involved in managing address blocks of various sizes. If we assume there is 80% usage at each level, we can easily calculate the overall usage. The following table proposes a set of hierarchical levels which we can reasonably expect within different amounts of address space. If a usage of 80% is achieved at each hierarchical level, then the overall usage will be (0.80 to the power of "n"). It is then possible to calculate HD ratio values from this value. Size range Level Utilisation HD ratio (prefix) (n) (0.80**n) (calculated) /24 to /20 1 80% .960 to .973 /20 to /16 1.5 72% .961 to .970 /16 to /12 2 64% .960 to .968 /12 to /8 2.5 57.2% .960 to .966 /8 to /4 3 51.20% .960 to .966 The levels of hierarchy listed above are based on assumptions about the likely size and structure of LIRs holding address blocks of these sizes. A reasonable HD ratio value may be 0.96 (a round figure which occurs within most of these ranges) from the table above. The following table gives the usage requirements for IPv4 address blocks from /24 to /8 for this value. IPv4 Addresses Addresses Util% prefix total used 24 256 205 80.11% 23 512 399 77.92% 22 1024 776 75.79% 21 2048 1510 73.71% 20 4096 2937 71.70% 19 8192 5713 69.74% 18 16384 11113 67.83% 17 32768 21619 65.98% 16 65536 42055 64.17% 15 131072 81811 62.42% 14 262144 159147 60.71% 13 524288 309590 59.05% 12 1048576 602249 57.43% 11 2097152 1171560 55.86% 10 4194304 2279048 54.34% 9 8388608 4433455 52.85% 8 16777216 8624444 51.41% Note: This table provides values for CIDR blocks, but the same calculations can be made for non-CIDR blocks. As an example, an LIR holding a total amount of address space equal to a /16 would be able to receive more address space when they had sub-allocated or assigned 64.17% of that space; while an LIR holding a /9 would be able to receive more space when they had sub-allocated or assigned 52.85% of their address space. Appendix C. References [RFC 3194] "The Host-Density ratio for address assignment efficiency: An update on the H ratio", A. Durand, C.Huitema, November 2001. [ipv6-address-policy] RIPE NCC document: "IPv6 Address Allocation and Assignment Policy" http://www.ripe.net/ripe/docs/ipv6policy.html [ipv4-address-policy] RIPE NCC document: "IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region" http://www.ripe.net/ripe/docs/ipv4-policies.html

2 2

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 04 Apr '05

04 Apr '05

>>> Well, this can be argued the otherway around as well. We know that >>> ISPs >>> filter out previously unused space, and that they are not very active >>> in updating those filters when IANA starts allocating out of new >>> blocks. Having all in well-known block would limit that. >> >> ...wouldn't we/you/they/all have to do some filtering the "other way >> 'round" if all of those prefixes are contained in _one_ superblock to >> guard against someone/something announcing (and potentially black- >> holeing(sp?)) a route for that /32? > >Eh, I would assume there is no /32 to announce and that more specifics >will always win. > >- - kurtis - In a perfect world - yes. But "per default" when you announce something in v6-world, you are "supposed" to announce a /32 (or maybe a /35) _and_ filter anything that is longer than that. I really don't see any benefit from adding complexity again, other than clinging to the well-worn conservatiopn goal from IPv4. Wilfried.

16 39

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 29 Mar '05

29 Mar '05

>No, what it means is: "People who inject routes in the global routing >table, for whatever reason, increase the cost of operating routers. So >for reasons of fairness and as a mild deterrent, these people should >bear a generous share of the costs associated with operating the RIR >infrastructure." Again, this implies the existence of some sort of cross-domain funds- transfers. As there is no direct and transparent relationship between ensuring uniqueness of address space blocks (RIR business) and those covering the cost of implementing the routing layer for the global Internet, it would simply be an address tax raised by the RIRs. There's not even the concept of "reverse funds" transfer from the RIRs charging for such addresses back to the LIRs. >A good way to do this would be to require everyone who wants such a >block to become a RIR and to charge address based costs only on the >number of blocks and not on their size. No, see above. [btw, I assume the string "RIR" in the previous paragraph is just a typo and that you meant to type "LIR". Otherwise this would be a clever move to kill the proposal - by sending them to ICANN for recogition as an RIR :-] And, I presume that addresses would only be distributed by way of an LIR anyway. So where is the point? >Note that I'm not saying these people should pay an artificially >inflated fee (although deep in my heart I would love that), just their >fair share. With your definition of fair for something you don't like :-) Scary... > It shouldn't be cheaper to obtain a special prefix than a regular one. Indeed, and then it should not be smaller or, rather, more difficult and risky to use. >Also, there should be limits on the number of special prefixes. Ahem, how many - and why? Wilfried.

6 10

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 25 Mar '05

25 Mar '05

>If even they don't push their routers hard, then even with phenomenal growth >over the next 5 years or so then what ever the current routers are then will >probably be able to cope. >If the routers can cope then the size of the routing table becomes a non issue >- that's what I'm trying to say. Looking at the fact that for a couple of years already the majority no longer cares (or even reads? much less acts on) the weekly routing table reports suggests that you are right. >Jon Wilfried.

1 0

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 24 Mar '05

24 Mar '05

>personally, i have no answer. We seem to be coming to the bottom of the pit :-) > sorry to make you read all this rubbish to find that. Fine with me. > why not show a bit of wimsey and block out >42 /32 chunks for this and have a three month bidding period to see >how much money the rirs can collect to donate to heal some of the >horrifying wounds of the latest natural disaster or unnatural us >imperialism? Aah, so this time at least we don't want to raise money for poor routers, but for victims of some sort of disaster or another. And why 42? (other than being "this" universal number) Wouldn't we be able to raise more money if we would give away more prefixes ;-) Or maybe just 32 x /32? Funny times, Wilfried.

2 1

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Joao Damas 24 Mar '05

24 Mar '05

OK, so I guess my point altogether is that I dislike special-ness. There seems to be agreement that DNS anycasting is here to stay so the only point of contention is the size of the prefix. Using longer prefixes does not add much to the conservation and introduces more exceptions. Even if other RIRs are doing /48s already why would introducing an additional chunk of swamp space with the potential for more likely large scale failure be of any benefit? If people agree with assigning the addresses for this purpose, which seems to be the case, just issue a standard allocation and be done. Regarding the issue of flap damp(en)ing parameters, I think we should really revisit the flap damp(en)ing recommendations again at RIPE 50. Joao PS: regarding entries in the routing table and the pollution it causes, keep an eye on RFCs coming soon. PS: regarding the use of "wrong DNS software", the TLD operator is running *SERVERS* and providing services to resolvers/users. The best they can do is provide as good a service as they can to their consumers, not preach to them about them running the wrong client side software.

3 7

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 24 Mar '05

24 Mar '05

>I would also be very happy if RIPE would charge enough money to people >wanting to do this to make them consider whether they really need it. ...this is just a fuzzy wording for: "Make the RIRs sell address space at different (and maximum) premiums, depending on how dearly the applicant needs the addresses at that particular point in time." I would not support such a proposal. Wilfried.

2 1

Re: [address-policy-wg] Policy proposal: #alpha: TLD Anycast Allocation Policy
by Wilfried Woeber, UniVie/ACOnet 23 Mar '05

23 Mar '05

Kurtis, >> Howeverm, the "out of a single block" is the part that really bothers >> me. Putting supposedly "critical infrastructure" as it is called >> elsewhere in a block that makes them all share fate in the event of >> network "optimisations" is still a bad idea. > >Well, this can be argued the otherway around as well. We know that ISPs >filter out previously unused space, and that they are not very active >in updating those filters when IANA starts allocating out of new >blocks. Having all in well-known block would limit that. ...wouldn't we/you/they/all have to do some filtering the "other way 'round" if all of those prefixes are contained in _one_ superblock to guard against someone/something announcing (and potentially black- holeing(sp?)) a route for that /32? >- - kurtis - Wilfried.

2 1

Registration Policy
by Thomas Thorne 11 Mar '05

11 Mar '05

To Whom It May Concern: How does a company or individual "own" the .biz, .info or similar URL suffix? Is it possible to register a new one? If so, at what cost? And do you allow someone to then own and profit from it? Thank you, Tom Thorne __________________________________ Do you Yahoo!? Take Yahoo! Mail with you! Get it on your mobile phone. http://mobile.yahoo.com/maildemo

3 2

Status of open actions
by Hans Petter Holen 04 Mar '05

04 Mar '05

Dear all, the next RIPE meeting is approaching in a couple months - It is time to review the action list. I have added the status as far as I know. http://www.ripe.net/ripe/wg/address-policy/action-list.html 47.3 Andreas Bäß Anycast for ccTLD: Complete discussion through Mailing List to draft formal proposal. Ongoing - published as policy proposal #alpha 47.4 Chair AfriNIC proposal for /22 minimum allocation size: Seek final consensus through the Mailing List. completed 47.5 Chair Changing the 80% rule for IPv4 allocations: Start discussion through the Mailing List. 48.1 Chair HD Ratio for IPv4: Take discussion to the mailing list policy proposal #beta 48.2 Chair Issues seen in IPv6 Allocation requests: circulate input on the mailing list. 48.3 NCC Issues seen in IPv6 Allocation requests: Propose re-write following mailing list discussion. 49.1 Andy Furnel Draft formal proposal on removing the 200 customer requirements for IPv6 49.2 Rob Blokzijl Publish draft Policy Development process published http://www.ripe.net/ripe/maillists/archives/ripe-list/2004/msg00058.html 22 Dec 2004 49.3 Working Group Continue discussion on the list of the IANA-RIR IPv6 policy 49.4 Eva Ericsson-Rabete Take discussion on Whois to the list 49.5 Alain Bidron Make a formal proposal on use of HD ratio for IPv4 policy proposal #beta

1 0

Beta test of new PDP
by Hans Petter Holen 04 Mar '05

04 Mar '05

As the new policy process proposed by Rob http://www.ripe.net/ripe/maillists/archives/ripe-list/2004/msg00058.html has not been finalized yet I have deceided to "beta test" the new process on new proposals received after today. The new process is a bit more structured that the previous one, and the previous one is open enough in its definition to fit the new one in this framework. Until the new process is approved and fully implmenented I'll maintain the list of proposals myself. Please let me know if you have any concerns with this approach Best Regards, Hans Petter Holen Address POlicy WG Chair

1 0

New AS Number Block allocated to the RIPE NCC
by Filiz Yilmaz 03 Mar '05

03 Mar '05

Dear Colleagues, The RIPE NCC received the AS Number Block 34816 - 35839 from the IANA in February 2005. You may want to update your records accordingly. Kind regards, -- Filiz Yilmaz RIPE NCC

1 0

Re: [address-policy-wg] IPv6 access to K-root
by Tim Streater 02 Mar '05

02 Mar '05

On Fri, 25 Feb 2005 21:00:05 +0100, Jeroen Massar wrote: >If you say they are lying, then complain to RIPE NCC that they are doing >their jobs wrongly. Apparently everybody who has gotten an allocation up >to now have been able to reason that they need the allocation under the >current policies. If you are not able to do so, though luck, you most >likely don't need it in the first place then. Sure they lie. I went on a BGP course a couple of years ago, and the instructor said that in his experience most people did because that's the only way to get what you need from RIPE. Current policies certainly don't fit us, for example. Looking in ripe-267, I see that in 5.1.1 there are four criteria for getting v6 space: 1) be an LIR - OK fine, we're an LIR. 2) not be an End Site - OK we're not. 3) plan to provide IPv6 connectivity to organisations - yes, we will certainly do that - to which it will assign /48s etc etc - no, we will never do that as all our customers are LIRs. 4) have a plan for making at least 200 /48 assignments to other organisations etc etc - no, we will never assign such space as all our customers have their own already. We manage one network (GEANT) for which we have a /32. There is another network (EUMEDCONNECT) which we manage at present, but in two years we are expecting that the connected NRENs will set up their own managing entity, and the infrastructure (including address space) will be handed over to them. I managed to get PI v4 space last year for this but it seems there is no such thing as PI v6 space so unless I fib and say that we have connected 50k end users to GEANT, I don't see how I can obtain separate, routeable v6 space for EUMEDCONNECT. We're an LIR, and an ISP, but we don't fit into the nice hierarchical tree that everyone assumes exists. For v4 we have an essentially similar problem. When GEANT's predecessor network, TEN-155, was being replaced we had to argue with RIPE about getting another /21 for GEANT. Well, now we have handed back the old /21 that we used for TEN-155. But the process should be easier than that. In short, I would advocate relaxing the rules about PI space. -- Tim

10 15

Re: [ipv6-wg@ripe.net] IPv6 access to K-root
by Iljitsch van Beijnum 02 Mar '05

02 Mar '05

On 2-aug-04, at 19:42, Andrei Robachevsky wrote: > K-root server has now IPv6 transport enabled. > k.root-servers.net. AAAA 2001:7fd::1 > A 193.0.14.129 > This information is also available from www.root-servers.org webiste. Since the ARIN micro allocation policy creates some problems, I was curious what kind of address space RIPE uses for k-root. A /32 "macro allocation", it turns out: inet6num: 2001:07FD::/32 netname: K-rootserver-net-20030829 descr: This assignment given to k-root.server.net I believe this ASSIGNment is in violation of existing IPv6 ALLOCATION policies. I would be very interested in learning any information to the contrary. Iljitsch van Beijnum

14 70